Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
How to trap a change in a ListBox after a MESSAGEBOX()
Message
De
12/03/2016 09:10:11
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Allemagne
 
 
À
12/03/2016 07:56:42
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Divers
Thread ID:
01632877
Message ID:
01632913
Vues:
45
Antonio,

I'm onto your subject - but argh, forgive me, your problem is not what you think you have.

I have given all information on this subject I have. I have told you what problems I see. You are looking at the wrong point with the wrong tools. You can repeat this as long as you like - it will not change the stuff you figure out. I'm through this on different points a lot of times. I'ts not traceable via debugger, your WAIT WINDOW can show nothing if not activated and if you have it only on the half of the places that act you will be lost. Your WAIT WINDOW gives you information you can not see the order things occur - like a simple ? will do.

You shurely can do boring work like,
SET COVERGAE and analyze it
SET EVENTLOG and analyze it

I have a general idea what goes wrong, that's what I have told you. I repeat The messagebox is changing the way stuff is activated or gets focus. Because a messagebox is a form of it's own, is activated while shown and the activation goes back to your form after the MB is closed. This sets focus - possibly not in the way you think of, so your listbox will never be clicked and will not change. Because your click in the event cue will be eaten away by the messagebox. After the messagebox the focus is handed back to your listbox - but without click.
In what way it gets focus - that's the problem.
It's in that information of the SET's above, but I shurely do not do that work except I have a problem of my own. Get the logs, search through it. It's not clicked, no item is changed, that's it. Display is wrong afterwards, without any doubt.

The basic idea behind valdation is:
Textbox.VALID
anything ok - no message at all. Just quietly proceed. No message is best message.
something wrong - messagebox - do not change focus, because the data is not valid - by RETURN .F.. (For that your messagebox does no harm, and the listbox will not get focus at all)

You might deal with the GETFOCUS and WHEN events, but this is even more anyoing.

>Lutz, I really do appreciate your advice and effort, but I think you're missing the point: I don't want to get rid of the MESSAGEBOX(). Please refer to the subject of this thread. What I want to know is if this is a problem with my code or a VFP's problem. Of course, it that is a VFP problem, then I'll have to take a different approach, but first I do want to sort it out.
>
>Regarding your observations:
>
>>#1 The WAIT WINDOW is misleading you. If you change to ? or debugout you will see the order the events will happen, while your WAIT WINDOW just show you the last message.
>
>I'm sorry, but this is irrelevant. The WAIT WINDOW is fired when there is a change in the ListBox, and that's what I'm looking for (again, please refer to the thread subject). Outputting elsewhere does not change a thing.
>
>>#2 The click event of the Listbox will never be called after the messagebox is raised.
>
>Yes, that's the problem that brought me here: how is it possible that a click in an enabled control does not raise its Click() event?
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform