Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to trap a change in a ListBox after a MESSAGEBOX()
Message
From
12/03/2016 07:20:01
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
 
 
To
11/03/2016 19:14:25
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Miscellaneous
Thread ID:
01632877
Message ID:
01632906
Views:
88
Hi Antonio.
(-_-)
You realy should follow advice to test. If you stuck to your ideas it's realy hard to test / explain anything. What will you miss if you follow advice just for testing and learning? If it figures out to be nonsense you allways can go back.

I have now executed your code. (To do the changes I have told you, just to secure my POV) It is as I have told you.

#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.
#2 The click event of the Listbox will never be called after the messagebox is raised.

I have altered your progam so you might see whats going on.
There is a checkbox that enables you to run the form with and without the messagebox, output is via ? and form is centered, output to screen.

HTH
LOCAL loForm AS aForm

CLEAR
loForm = CREATEOBJECT("aForm")

m.loForm.SHOW(1)

DEFINE CLASS aForm AS FORM   
 ALLOWOUTPUT = .F.
 AUTOCENTER =.T.
 ADD OBJECT theList AS aList
 ADD OBJECT theText AS aTextBox WITH LEFT = 100

 ADD OBJECT chkX AS CHECKBOX
 chkX.LEFT = 100
 chkX.TOP = 50
 chkX.CAPTION = 'No Messagbox'
 chkX.VALUE = .F.
ENDDEFINE &&aForm AS FORM

DEFINE CLASS aList AS LISTBOX   

 PROCEDURE INIT   
  THIS.ADDITEM("Item 1")
  THIS.ADDITEM("Item 2")
  THIS.ADDITEM("Item 3")
  THIS.LISTINDEX = 1
 ENDPROC &&INIT

 PROCEDURE INTERACTIVECHANGE
  ?"InteractiveChange(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
 ENDPROC &&INTERACTIVECHANGE

 PROCEDURE PROGRAMMATICCHANGE
  ?"ProgrammaticChange(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
 ENDPROC &&PROGRAMMATICCHANGE

 PROCEDURE CLICK
  THIS.SETFOCUS
  ?"Click(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
 ENDPROC &&CLICK
ENDDEFINE &&aList AS LISTBOX

DEFINE CLASS aTextBox AS TEXTBOX
 PROCEDURE VALID
  ?'valid'
  IF !EMPTY(THIS.VALUE) THEN
   IF THISFORM.chkX.VALUE THEN
    ??' just print'
    ?"Some validation..."
   ELSE  &&thisform.chkx.value
    ??' Messagebox'
    MESSAGEBOX("Some validation...")
   ENDIF &&thisform.chkx.value
  ENDIF &&!EMPTY(THIS.VALUE)
 ENDPROC &&VALID
ENDDEFINE  &&aTextBox AS TEXTBOX
Update:
QWERTY?
#1 QWERTZ
#2 Dvorak

(just kidding)

>>
>>It's general advice. Wait Window is so CP/M
>>
>
>Well, QWERTY is so Remington and yet, here we are ;-) DALVIK
>
>Now, seriously, as I told, its purpose is to let the demonstrator to be self-contained. If one is willing to try, a simple copy & paste & run will do. I spent my fair amount of debugger time before coming to UT with this, but wouldn't expect others to have the same commitment.
>
>>So, you say that if you pint instead of messagebox the error remains. Then it is not bound to the messagebox. Something else is the problem.
>>You might run through your code and trace / breakpoint the value. Note, this is tricky. You can set THIS.listbox.value to the watch window end set a breakpoint to it. But this will go out of focus. so you need to bound this to a public variable ant watch for publicvar.listbox.value. You might find the place that alters your value this way.
>
>No, what I said is that it won't solve the problem, t4hat is, "how to trap a change in a ListBox after a MESSAGEBOX()".
>
>>Nope. I let the user enter and check after they try to save. User (I'm in a small corner) found it ugly to have those checks on every boring text box. I was happy about it.
>>A textbox that excepts a number is a number, one that excpects date is of date type. Why should I deal with chars? It would only be meaningfull for ranges or uniqness - but unique could be over more then one field so this is on save too.
>>All what I say - it's my style and I'm happy to have not this frustrating stuff in each and every input object. I have depencies for enable etc. - but they run over central methods on eventbinding.
>>Also VFP is by design a pain with VALUE, a lot of times INTERACTIVECHANGE needs a THIS.SETFOCUS to have THIS.VALUE or more controlsource set to the value entered.
>>
>
>Data typing, field length, input masks, all these are constraints that impose validation at input time, long before user clicks save.
>
>>
>>Have nice weekend.
>
>The same to you, Lutz, and thanks again.
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]
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform