not responding

[Nigel Gomm]

is anyone else seeing their vfp 9 applications (i.e. a built .exe) going non-responsive?

no error messages... just freezes and you have to let windows close the application.

a few customers have had this happen a few times and i was expecting it to be AV or some such but just had it happen on my PC.

coverage shows nothing interesting (or consistent).... my code isn't doing anything.

recent coverage files show the most recent instruction to be a textbox .when() returning and another shows a form .refresh() finishing.

Windows 10 in all cases. don;t have build numbers for all. windows 10 pro version 1809 build 17763.316 in my case. Windows Defender only (but don't tell anybody).

there are timers and activeX in the app but the most recent crash (on my PC) was at startup during a login prompt and before anything 'exotic' gets launched.

?

n

 

[Nigel Gomm]

hmmm... might be after bringing the app back to the foreground after working in another window.

which reminded me i had in the past tried to bindevent to _screen.activate. it hadn't worked (my proxy event never fired) but i'd left the code in there.

I'll see if it happens with that bindevent() removed.

n

 

[Olaf Doschke]

I recently programmed one main application calling another one, I considered the separation because in a separate test project a new form with web browser control worked, while it failed in the environment of the main application/project. I'm still not sure why, some setting, but also likely a timer and what it does and the VFX framework used.

I also found out the web browser control events only happen, when it's visible including the form it's on.

The best way to avoid minimize/maximize I found out was to shift the inactive _screen left of the display (negative left coordinate). I didn't do that with BindEvents to _screen activate/deactivate at all. One button in the main app causes switching to the other process/_screen and closing that form reactivates the main app. It's not always applicable, as you might have to do with a multi-display environment and then a screen translated to negative coordinates can be visible on a left display, if the main display is the right one instead of the normal setup.

I did the second application as OlePublic class and that caused some trouble with events. If you look at the last three or four threads I started they are about different problems all related to this scenario.

In my case _vfp.ole... properties helped and as I said in one of the threads starting a timer that executed an action/event later after the method already returned to the caller helped to prevent a deadlock in the windows events queue (I guess). In short: decoupling.

I don't know what's the second application in your case, likely candidates are Office applications you control via ole automation, then _vfp.ole... properties may apply, though that applied to the ole application I did myself, but also the main app (client) has the _vfp.olerequestpendingtimeout property.

All in all, I know have a nice framework of creating automatable applications quite like office applications are.

Aside from that, I remember how BindEvents to windows messages was a solution to application activation/deactivation events. See

http://doughennig.com/papers/Pub/200501dhen.pdf,

especially binding to WM_ACTIVATE.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

the 'other' application could be anything on the user's PC.... it's windows so they flick back and forth just as you and i do.... so the activate/deactivate is not something i need to control or limit.

i'd been trying to handle the activate event for reasons that escape me now.... it just occurred to me that the application had been in the background when i switched back to it and discovered the 'not responding'... and that reminded me of the bindevents().

i'm guessing no one else is seeing this so it's something unique to me rather than VFP not behaving on recent builds of win10. I think that's a good thing....

n

 

[Nigel Gomm]

alas it is still happening.. so the bindevent() (and it seems deactivate/activate) wasn't the problem.

 

[Mike Lewis]

Nigel,

My apologies if I have misunderstood the problem, but if you are saying that the application is running but is not visible because it is behind another window, then the following code should fix that:

DECLARE INTEGER SetForegroundWindow IN WIN32API INTEGER
SetForegroundWindow(thisform.HWnd)
CLEAR DLLS "SetForegroundWindow"

If this is not relevant, just ignore it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Nigel Gomm]

no it's visible

but windows adds a (not responding) to the title bar and the entire _screen greys out.

only option then is to 'end process' in task manager or click on the _screen and windows comes up with the 'close now or wait for application to respond' dialogue.


n

 

[Tore Bleken]

Have you tried to let the program run for a while?

 

[Olaf Doschke]

As you said the coverage log last reported a "when" event.

What are you doing in that when event? Are you rejecting focus? Can it happen the current form has nothing taking the focus?#

Because that way of not responding means the application isn't responsive and that may happen if a form has nothing able to take the focus so an infinite loop of endless events happens.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

Tore,

15 minutes and more.

all without anything showing in the coverage report.

n

 

[Tore Bleken]

And I guess that it's not something that you can reproduce?

 

[Nigel Gomm]

Olaf,

one of the coverage reports showed a when returning.. but not all. The 'current' form is also not always the same form.But all forms have something that will take focus.

And it's not consistent. same form, same user action will work fine and then.... not.

n

 

[Olaf Doschke]

Events with no code don't show in the coverage log, it only logs code lines executing.
Have an experiment and add a timer to _screen logging some things like _screen.activeform.name and _screen.activecontrol.name (if those references are not NULL) and maybe anything else of interest.
The first thing of interest would be, if that logging still works while your application is not responsive. and if not, what was last logged, of course.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

What about log file sizes?

If you have loops like these, the log file size can explode:

DO WHILE condition
   DOEVENTS
ENDDO

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

Tore,

no i cant reproduce at all.

The worst affected user has it happen perhaps once or twice a day - i've asked his IT people to look in the windows event log for clues and to rebuild the PC.

But i've heard tell of it elsewhere.

Not sure when this began... recent versions of the app use a mariaDB server (using the mysql ODBC driver). It may have been happening on older versions that use networked .dbf files but i would have dismissed it as SMB problems (which is why recent versions use MariaDB).


Olaf,
There are already timers running that would appear in the coverage if 'anything' was running. But you're right... windows events have to be the first line of inquiry. i'll add diagnostics into all the base class's events and see what that shows.


n

 

[Nigel Gomm]

aha! early days yet but..

_vfp.autoyield to .f. before SQLEXEC() seems to have solved it.

this is with the mysql ODBC driver.


n

 

[Olaf Doschke]

No idea how that should be related. _vfp.autoyield help topic is mentioning queries, but in that case native queries VFP SQL to DBFs is meant, not SQLExec. SQLExec will typically run synchronous, unless you use SQLSetProp() to set "Asynchronouse" to .T., so if this is MySQL ODBC related I'd rather try SQLSetProp(handle,"Asynchronous",.F.) and see if that fixes the app behaviour.

If you do set this .T. to make an app more responsive and not sticking at the SQLExec line when a query needs longer, you'll also need to program a loop waiting for the result or process this in some form of callback. It's just there is no way to tell SQLExec what to call after the query result exists. If a driver can use threads you may fetch results before the query finishes. A simple GO BOTTOM would then force VFP back into synchrouns mode as you can only go bottom after the last row is fetched and IIRC then GO BOTTOM does not just go to the buttom of the current state of the result cursor.

Anyway, long runninng queries of course can be related to a situation of VFP not repsponding. Setting AutoYield to .F. would magnify that behaviour, though, not hinder it. You're explicitly saying no event processing until I'm finished.

As the help says WAIT will not cause such a wait state allowing the processing of Windows events like that querying a process to be idle or active. And since SQLEXEC is synchronous by default you'd even not execute Doevents or get back to READ EVENTS for windows event processing.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

asynchronous is left to default.

think the mysql driver is different from the MS SQL Server driver in this regard. noticed when i first switched to the mysql driver that timers were firing during a query and added code to prevent them doing anything disruptive

it gets even more curious though. What led me here was a one-off error message.
A form calls a .prg that leads to a SQLEXEC query. During the execution of that .prg the form's resize event fired. one of the object's on the form had some resize code that did a WITH/ENDWITH.
The object name referenced by the WITH then turned up in a TRY/CATCH error message in that .prg. Just the once.
I've been wary of WITH/ENDWITH ever since Doug Hennig told at a great lakes conference how he got rid of every C5 error in an application by removing all WITH/ENDWITHs. This specific one may have been asking for trouble because it did a WITH EVALUATE("this."+xyz).

as i said early days yet... but so far seems to have cured it.

n