VFP MENU FLICKER
While I'll be delighted if anyone comes forward with a solution to this problem, I'm not expecting it. I'll settle for better ways, than I've so far tried, to diagnose it.
It is a perennial problem I've failed to resolve for about 15 years. The symptom is simple to describe. In certain circumstances, the menu bar created with foxpro's menu.mpr or derivatives will suddenly start to flicker as though it's being refreshed or reloaded about 5-10 times a second.
I've never managed to figure out what causes this behaviour because it NEVER happens in the programming environment, only in the compiled exe.
I've tried writing loop traps and counters. I've tried writing simple logic traps which prevent any calls to run the menu code once it has been activated.
It has also, till now, been a low priority because it's occurrence has been rare, intermittent and unpredictable. On some installations it happens more than others (say, daily) and on some never. These differences persist even on identical workstations with identical sofware installed and running on the same network.
It's just become a priority because a new form I've added to the mix is causing the problem in an entirely predictable and routine manner - i.e. every time the modal form is invoked, on release back to the main form, we get the flicker. The flickering, incidentally, doesn't prevent the sofware working although it does become sluggish. Some users simply ignore it. Others are disturbed by it.
At first, on finally creating a predictable cause, I was almost pleased. As we all know, when the behaviour happens on cue, it should be relatively trivial to figure out what's going on.
I added an optional "Coverage" option which is available only to me when I log on as admin. I ran the main form, invoked a DIFFERENT modal form (which has never caused the problem), exited the modal form, exited the main form, closed the program and renamed the saved coverage file.
Then repeated the above but with the offending new modal form, confirmed the flickering, exited program.
Then compared the coverage reports. They were effectively identical.
Yet, under "normal" behaviour, upon exiting the non offending model form, CPU usage by my program remains negligible (<1%) while, on exiting the offending form and going into flicker mode, CPU usage jumps to between 17 and 23% and stays there till I close the program, clearly proving that some huge amount of unnecessary looping is going on. How it can do this without revealing itself in the Cover logs is way beyond my imagination.
So, how else can we track behaviour like this in the compiled exe?
It is a perennial problem I've failed to resolve for about 15 years. The symptom is simple to describe. In certain circumstances, the menu bar created with foxpro's menu.mpr or derivatives will suddenly start to flicker as though it's being refreshed or reloaded about 5-10 times a second.
I've never managed to figure out what causes this behaviour because it NEVER happens in the programming environment, only in the compiled exe.
I've tried writing loop traps and counters. I've tried writing simple logic traps which prevent any calls to run the menu code once it has been activated.
It has also, till now, been a low priority because it's occurrence has been rare, intermittent and unpredictable. On some installations it happens more than others (say, daily) and on some never. These differences persist even on identical workstations with identical sofware installed and running on the same network.
It's just become a priority because a new form I've added to the mix is causing the problem in an entirely predictable and routine manner - i.e. every time the modal form is invoked, on release back to the main form, we get the flicker. The flickering, incidentally, doesn't prevent the sofware working although it does become sluggish. Some users simply ignore it. Others are disturbed by it.
At first, on finally creating a predictable cause, I was almost pleased. As we all know, when the behaviour happens on cue, it should be relatively trivial to figure out what's going on.
I added an optional "Coverage" option which is available only to me when I log on as admin. I ran the main form, invoked a DIFFERENT modal form (which has never caused the problem), exited the modal form, exited the main form, closed the program and renamed the saved coverage file.
Then repeated the above but with the offending new modal form, confirmed the flickering, exited program.
Then compared the coverage reports. They were effectively identical.
Yet, under "normal" behaviour, upon exiting the non offending model form, CPU usage by my program remains negligible (<1%) while, on exiting the offending form and going into flicker mode, CPU usage jumps to between 17 and 23% and stays there till I close the program, clearly proving that some huge amount of unnecessary looping is going on. How it can do this without revealing itself in the Cover logs is way beyond my imagination.
So, how else can we track behaviour like this in the compiled exe?
ASKER
Greetings PCElba
Thanks for the above, and I'm sure some it is bound to be relevant, although they are the nooks and crannies I've already pored over for literally more than a decade! Still, as we've recently seen, I am capable of looking at a typo for days without identifying it, so anything is possible!
I have bullied the problem into submission but without determining the cause. Essentially I've proved it's down to my customised Form class.
I did this by stripping everything off the form and just giving it a Close button. Even that produced the flicker.
Yet, ALL my forms are based on that class, and I call many different modal forms from my main forms and none of the others have ever caused this predictable version of the problem. Nevertheless, when I'd gone that far, I started from scratch and rebuilt the form using the standard VFP form class and simply cutting and pasting all the stuff from the original into the rebuild. I did this a bit at a time, testing for flicker effects as we went, but found I could copy across absolutely everything and the rebuilt form is now working perfectly and produces no flicker.
So that problem has gone away but I'm still keen to figure out what can possibly be causing the problem in my subclass ONLY in this one case and NOT on calling or closing any other forms.
I also think I got a clue as to another potential trigger for the flicker , though it can't be related to the form subclass. I accidentally triggered the flicker in the programming environment. I use a heavily modified version of Ken Weber's 1999 Combobox (typically called CBOSRCH) as my main popup tool for small lists. I've added code all over the place, including a few lines in the "MOUSEMOVE" method. And I happened to float my mouse across an active popup while in debugging mode and my system went into a crazy loop and everything started flickering. That has given me a clue as to what lines of my own code may be causing the problem. I think I've accidentally set up an infinite recursion call which fires under certain circumstances.
I disabled the code and the problem evaporated. Which gives me a plausible way to investigate it. The problem is that it can't be related to the form subclass as the kind of calls I'm talking about only ever get written into databound objects like textboxes, editboxes, checkboxes etc Never forms.
What would be really helpful at this point is suggestions on other ways to identify loops in the running executable when none of the traps I've so far laid have caught the prey. I think the flickering is misdirection! A symptom of something more fundamental, hence my attempts and preventing menu looping were futile. Trying to think of some other universal object whose instantiation I can count...
Thanks for the above, and I'm sure some it is bound to be relevant, although they are the nooks and crannies I've already pored over for literally more than a decade! Still, as we've recently seen, I am capable of looking at a typo for days without identifying it, so anything is possible!
I have bullied the problem into submission but without determining the cause. Essentially I've proved it's down to my customised Form class.
I did this by stripping everything off the form and just giving it a Close button. Even that produced the flicker.
Yet, ALL my forms are based on that class, and I call many different modal forms from my main forms and none of the others have ever caused this predictable version of the problem. Nevertheless, when I'd gone that far, I started from scratch and rebuilt the form using the standard VFP form class and simply cutting and pasting all the stuff from the original into the rebuild. I did this a bit at a time, testing for flicker effects as we went, but found I could copy across absolutely everything and the rebuilt form is now working perfectly and produces no flicker.
So that problem has gone away but I'm still keen to figure out what can possibly be causing the problem in my subclass ONLY in this one case and NOT on calling or closing any other forms.
I also think I got a clue as to another potential trigger for the flicker , though it can't be related to the form subclass. I accidentally triggered the flicker in the programming environment. I use a heavily modified version of Ken Weber's 1999 Combobox (typically called CBOSRCH) as my main popup tool for small lists. I've added code all over the place, including a few lines in the "MOUSEMOVE" method. And I happened to float my mouse across an active popup while in debugging mode and my system went into a crazy loop and everything started flickering. That has given me a clue as to what lines of my own code may be causing the problem. I think I've accidentally set up an infinite recursion call which fires under certain circumstances.
I disabled the code and the problem evaporated. Which gives me a plausible way to investigate it. The problem is that it can't be related to the form subclass as the kind of calls I'm talking about only ever get written into databound objects like textboxes, editboxes, checkboxes etc Never forms.
What would be really helpful at this point is suggestions on other ways to identify loops in the running executable when none of the traps I've so far laid have caught the prey. I think the flickering is misdirection! A symptom of something more fundamental, hence my attempts and preventing menu looping were futile. Trying to think of some other universal object whose instantiation I can count...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
if the VFP program is waiting for user input but Task Manager is showing high CPU load for VFP Runtime then we are almost sure something went wrong inside the Runtime module and that's beyond our knowledge obviously.
I've never seen VFP menu flickering and I don't know your source code and VFP version. Obvious program flow is following:
1. Initialization
2. Menu creation
3. READ EVENTS command
4. Now the code waits for events
5. Processing events invoked by menu selection, by timers, or by hotkeys
6. and if some of the event ends by the CLEAR EVENTS instruction then program continues by the instruction following the READ EVENTS command which is some cleanup and exit obviously.
Modal windows in above scenario do not mean problems. Important is to do a cleanup which means to destroy unused forms, windows, and objects etc. You may read more about it here: http://fox.wikis.com/wc.dll?Wiki~ManualGarbageCollection (remember it does not necessarily help...)
If your code is organized differently then you may solve various incompatibilities. I would recommend to redesign the code or try to do it at least.
Of course, debugging the running VFP Runtime is possible in Visual Studio attached to the process or in any other debugger derived for this purpose but to redesign the code is much easier for us.