Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
CLEAR ALL within an event or method
Message
From
11/01/2013 09:45:35
 
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01562079
Message ID:
01562142
Views:
65
>Issuing CLEAR ALL within an event or method for an active control or object generates a Visual FoxPro error message.
>This bothers me in this situation:
>1 In the Init() of an object an error occurs.
>2 The errorhandler offers the option to Abort.
>3 The Abort has separate code for the runtime situation and the development situation.
>4 In the development situation I have a line CLEAR ALL.
>
>It generates an error without a number: ''Cannot clear the object CMDBROWSE because it is in use."
>
>I have unsuccesfully tried several techniques to release the form that contains the object beforehand, for example:
>
for each loForm in _screen.forms
>	if lower( m.loForm.class ) = "viafrm_viajob"
>		m.loForm.destroy()
>		m.loForm.release()
>	endif
>next
>release loForm
>
>Advice is welcome.


I have had to handle conditions like this in the past. They were difficult to work through. I ultimately wound up creating something like a "DoAThing" container class. I would create a single global instance of the class at startup, and reference it anywhere I needed i.

This class had methods and parameters allowing me to pass the command I wanted to execute as a text string, along with two optional tests. One was a condition to check before executing (also passed a text string), the other was a timer delay in milliseconds.

I would append the command, optional condition, and optional timer delay, to an array. The class had a timer which would examine the array once every so long (such as every 250ms when there is something in the array, timer was disabled otherwise), and if there was a timer value it would count that value down to zero then execute. If there was a condition, it would check the condition then execute when true. If there were neither, it would just execute the command.

Doing this I had the ability to introduce any custom "trigger" into my code which would be operated at some future date or time, based on some condition. It would work when the creation of a global variable "PUBLIC glNowIamDone" came into existence, for example, or perform the operation 2 seconds later. Any desirable test would be executed, but it had to be executable from the "remote code location" ... no references to "thisForm" or whatever.

It worked ... worked well ... was a bit hackish ... but it never failed.

Hope this helps.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform