VFP error message poping out

[svey]

Good day,

I am using everyday a VFP app file. I keep getting an error message popup saying : Cannot quit Visal Foxpro. I can click ok and that closes the box and the app still runs until the same error message pops up again.

I would like to resolve or at least hide the error message.

How/where do I need to look?

Tx

svey

 

[GriffMG]

Do you have the source code?


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Mike Lewis]

This is a very common question. In short, the message appears either because you are trying to quit VFP while READ EVENTS is in force, or while a modal form is active.

If you don't understand those two terms, take a look at my article: How to avoid the Cannot Quit Visual FoxPro message. That should tell you what you need to know, but come back here if you need any further explanation.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Is this always happening or do you see a pattern, for example after you used some feature, when you try to quit while a report preview is shown, or anything in that direction?
You can intercept errors in many ways and also suppress them. Problem is this "Cannot quit FoxPro" message looks like an error message, quacks like an error message, yet it's not a duck. And not an error.

Most probably you are in a state where a READ EVENTS wasn't yet paired up with a CLEAR EVENTS, which you surely can't control as a user. It means a typical quit menu item does a READ EVENTS and usually works, but if you do that in a state where a messagebox is active or a report preview - the term is modal state, that doesn't really work, and then VFP gets into a state where it refuses to quit.

If that happens to a VFP developer while developing and he can at least manage to suspend the program, so the command window will show up again (which automatically hides when code runs), you can type in two things that usually work out well:

ON SHUTDOWN

and then

QUIT

The first command just ensures that clicking the X close button, or using the File->Exit menu item, or executing the command QUIT just do their default behavior, or - as the term SHUTDOWN suggests correctly, if you shut down the computer. Even if a READ EVENTS currently is active a QUIT then works. But there are harder cases I've seen - the hardest case is that the command window is shown and you can type commands, but entering them does not execute them. That becomes apparent, if you do something that should have a direct visual effect, like using ? 'hello, world' should output hello world on the screen. Then you're quite busted to get any grip, the debugger could help, but of course that's even further from what you can use as a user, the debugger isn't part of the runtime of a VFP application at all. So let's stop here.

All in all, as a user you don't have the development environment including its command window and debugger. So no chance for you, but to terminate the process in the task manager. If the app is not quitting because it's in the READ EVENTS state and you have no means to cause the CLEAR EVENTS, there is no chance for you. It could be that the quit/exit menu item does CLEAR EVENTS and that's not bad design, but in cases that happens when - lets oversimplyfiy this, the READ EVENTS does not detect it's matched with a CLEAR EVENTS, but some exit code also removes the menu so you can't repeat using it and causing CLEAR EVENTS... you're stuck.

Overall, there's a design flaw in that application that most probably only effects exactly that: Quitting the application. If everything else works okay, it's mainly an inconvenience you can only report to the developer or company and describe how to reproduce it, ideally. So a developer can fix an issue.

If you're the developer the simplest program you can run is just READ EVENTS. If you do that and try to exit VFP you get that "Cannot Quit Visual Foxpro" message. You can also see if you establish a simple ON ERROR Messagebox("error") the error event (ON ERROR) isn't triggered. It's a message, but not an error.

You have a case of not programming with one simple rule in mind: Always open and close brackets, like using both READ EVENTS and CLEAR EVENTS. Like creating objects and also releasing them eventually. Or - in developer speak - destroy or "kill" them. And there is what the task manager offers to any user (unless the task manager is taken away from users by group policies), the emergency stop, to end tasks and processes. It's your only tool from outside, and in special cases even that doesn't get a grip on a process and only a shutdown/restart fixes it.

Chriss

 

[Chris Miller]

To get on the best practice side of this problem, to avoid it overall, a best practice design has several parts.

The core is still having a READ EVENTS (exception from that rule is using just one main modal form that takes over a role the READ EVENTS has). A menu item doing CLEAR EVENTS can work, but is not the best idea. Even sample code in VFP help uses CLEAR EVENTS as code inside the DESTORY of a form, so it happens as side effect of actually ending what the application mainly is - the main form.

Another part is establishing an ON SHUTDOWN routine as described in

https://www.vfphelp.com/help/_5wn12p9hy.htm

And within that you have to think about all the closing brackets that are due to happen or being triggerd. Closing all forms, rolling back or committing all database transactions (see TXNLEVEL), there are many things and also special events in object like Destroy in general in any class, QueryUnload, Unload in form classes, the Release method (not an event, but by default a method to force a form to quit). And there's more pitfalls you can have like circular references of objects therefore not quitting, etc. There are dependencies like settings per datasessions, forms with a private or shared/general datasession and even datasession objects on their own not bound to forms.

Also the programmer can use the most forceful way out and declare the windows API function TerminateProcess:

https://learn.microsoft.com/en-us/w...adsapi/nf-processthreadsapi-terminateprocess,

but it should only be a fallback after doing things in an ordered way, like preparing ingredients, combining and using them and finally also removing the mess you made while cooking. Just think bra-ket, if you do something that opens a bracket, in the most general way of thinking about brackets - opening, starting, later closing, ending something - at the same time think about the last step to do, the bracket closing, cleaning up step.

Chriss

 

[svey]

Tx for your answers.

I am the enduser not the programmer.

GriffMG

I have looked for the source code. All I have is the datawork.exe and the datawork.app.

I have asked it if they are aware of where the original files could be. The programmer died a few years ago so I am not sure how much hope I have of finding the source code.

I will read the suggested links.

Tx

Yves

 

[Chris Miller]

Well, as the end user you mostly have Task manager...

no chance for you, but to terminate the process in the task manager

If it's really the READ EVENTS state, that's most often the cause for this message, it's also quite reassuring that terminating the process does no harm, you're actually "on" that code line READ EVENTS, which waits for events (key pressing, mouse moving, clicking, etc) to happen, so you're in the inactive ground state, the least problematic state to exit from, even if doing so forcefullly.

Chriss

 

[svey]

The popup is coming up when the program sits idle.

All IT could find is are the file with the .app or *.exe extensions.

 

[Chris Miller]

When the program is idle, a try to quit it is causing that message (popup). So if it has a timout inactivating itself, that fails, if there is anything trying to quit processes and only hitting this app/exe (unintentionally or not), it fails to quit.

One thing is for sure, this message does not come from an idle sitting state alone, there's nothing broken with that concept in FoxPro in itself. It only pops up when this application should quit in a wrong way (i.e. not issuing CLEAR EVENTS in its code).

Is it sitting there on a server and once in a while when you check it you see that popup? Or does it come up if you do something else, perhaps also in another application, do you see the live moment, can you correlate this to something else, perhaps in the Windows Event log? If you find something that you can replicate this would help.

Chriss

 

[svey]

I have recorded (with iphone) what is it I am talking about.

https://drive.google.com/file/d/17zNfcePu6Q3uJ4OW84qwR6WSV7BPPpfZ/view?usp=sharing

 

[Chris Miller]

Does that happen alwas just a few seconds after starting it? I see you just hover the mouse a bit, not really doing anything.

What's intersting to me, shortly after the "Cannot Quit" message pops up there appears a symbol on the taskbar of that window. Are you using any tools that autodetect windows and hook into their titlebar, add some context menu there? It might be this, which causes that effect. I don't see such an icon added into the main application window, but you have something there, that's not normal. Definitely not for just a messagebox of the Cannot Quit message.

Chriss

 

[svey]

Yes Chris, I get the error message after a few seconds and the same message will reappear again after closing the box. Most of the time, I will be able to run whatever application I need to run but VFP crashes and closes completely at times.

Is there anyway to recuperate the source code from either the exe or the app files?

Yves

 

[Mike Lewis]

Svey, I hadn't realised you were an end user rather than the developer, so clearly the article I referenced in my above post won't help. Sorry.

This really does look like an issue that only a programmer can solve, and only if they have access to the source code.

One thing I'm curious about: You say the programmer died a few years ago. That suggests that the application has been in use for a long time. So has this problem only just started to arise? If so, it must have been caused by some change in your environment or system. If you can identify what that change was, we might be able to give some more help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Is there anyway to recuperate the source code from either the exe or the app files?

There is a utility called ReFox (

https://www.refox.net/),

but it is very hit and miss. How well it works depends on several factors, not least whether the programmer encrypted the executables. But it would certainly be worth a try if you have no other option.

But even if you do retrieve the source code, you will still need to find a local VFP developer who can solve the problem and rebuild the application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[svey]

Good day,

I have been using this for about 2 years now, the problem started 12-15 months ago or so. It could be an Win10 update that caused the problem because no updates were applied to VFP.

Tx for your help

Yves

 

[Chris Miller]

VFP itself and EXE built with VFP work on Win95 and above, also Server OSes. There are some known issues, some of which are fixed or have workaounds, but the "Cannot Quit FoxPro" message is not among them, not in conjunction with any Windows verrsion including Windows 10 and 11 and the several builds. There were many suspicions about reasons ccertain things started to fail, but only one, I actually know - General fields functionality, nothing that has to do with your case - was actually due to a Windows change.

And as Mikes article shows and what I wrote about experience with this behavior, this message and status is well known, but can be overcome from within and is in itself not a bug or an error of FoxPro, at worst you could call it too strict design and too strict from the runtime.

You make me think, if this worked for the first 9-12 months, what changed? It's a long period of 3 months you're not sure exactly when it began so you can't correlate this with which other changes. What about the icon I saw and mentioned, can you tell what this is?

It appears shortly after the message, which - I know - clearly suggests it's not causing this. Just seeing this picture you know already the Foxpro message appears first. But as I already said, this must be something not coming from within Foxpro, FoxPros runtime, EXEs built with Foxpro, nor is it a Windows OS feature, it's some third party tool, that seems to hook into any and every Window you have - if it can - to offer some functions from the titlebar. And this may cause VFPs process to quit, which it can't in that state, thus leading to that error. This exact same thing might have tried to hook into the main form titlebar, didn't manage and caused the application to get a shutdown signal leading to that problem.

If I think more generally about this there are more things that can happen with any process, like antivius scanning or hooking into processes. Have you tried to run with antivirus paused/deactivated?

Last not least, today your video causes an exception while playing, I'll forward it to Kaspersky and Malwarebytes for further inspection.

Chriss

 

[svey]

Hi Chriss,

The icon is the Displayfusion Pro 9.9 message offering to "Move window to next monitor".

I will have to wait to try disabling the antivirus tonight when I will be on my own computer (not my work computer)

Yves

 

[Mike Lewis]

I will have to wait to try disabling the antivirus tonight when I will be on my own computer (not my work computer)

Well, that gives rise to an interesting question:

Are you seeing this problem on your own computer, your work computer, or both?

If it's not present on both computers, can you identify what's different between your home and work machines? (And check that before you test the disabling of the antivirus.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Can you disable Displayfusion and see if it is perhaps that tool?
I'm not sure, but the main window appears to have a large titlebar, that's not the original Windows/Foxpro Form titlebar. There are ways you can make Titlebar and border of forms invisible and then drawyour own within the inner part of a form, the canvas, as it's called. And that could lead to Displayfusion failing to hook into the main application form and somehow causing it to get into that state of wanting but failing to quit.

Edit:No, the titlebar is normal. I can (still) also test this on my PC and see if it triggers this state. It would be interesting to know and prevent this in collaboration with the vendor of DisplayFusion, though I know Foxpro Windows only differ in the canvas part from normal Windows, the border/titlebar is the standard of Windows and also adapts, if you use a Foxpro executable on different Windows versions, so anything including DisplayFusion should be able to work with VFP windows, too. But we'll see...

Chriss

 

[svey]

I had already try with DisplayFusion running or not with the same results.

I do get the same popup on my home computer/work computer but I had never tried to disable the Antivirus on either box. Since I would need to involve IT at work to disable the antivirus, I will try it at home tonight.

Yves