Process not ending

[Cliff Nichols]

I am having a problem tracking down a bug that when I close my program under certain conditions, it appears the program ends, but is still listed in the processes and is actually still running.

In my case if I am scanning the computer to open a certain serial port, and I close the program while its process of Open File, check if device attached, Close file that the process remains running.

So I figure thats the part of code to look at, but putting in a trace to write to a file shows nothing. and if I try the same under debug, and animate, then when I close, I do not see the ending process of steps....it just ends.

If I am done scanning, or found my port and then close, everything closes fine and the program is not listed in the processes anymore.

The only other places I can think to look is in my statusbar, or richedit routines because the scanning shows its status there, but not sure what to look for.

So some fundamental questions

1. Could a file opened with Freefile, somehow not get closed? (but my ending routine, purposely closes it if open, so I don't think thats it
2. Could Streamin somehow be not processing a message in its callback, and not passing it on and creating a endless loop that I am not aware of? (like a DefFrameProc not used would do to me?)
3. Some similar thing with a statusbar?
4. If a control or a dialog or a window that has been destroyed, and some routine try to do something with it cause a program to continue?

Just some thoughts....but maybe someone can point out something I can do to track my closing, or something I do not know may be causing the problem? I am working on some code to demo the problem, but can not seem to replicate it yet :confused2:

[Adam J. Drake]

Is your main dialog MODAL or MODELESS? If MODELESS, are there any conditions in which your message pump may not exit when the dialog is destroyed?

[Dave Biggs]

In my case if I am scanning the computer to open a certain serial port, and I close the program while its process of Open File, check if device attached, Close file that the process remains running.

Couple of thoughts:

• Maybe you need a check in your scanning (thread?) or while checking if the device is attached so you can deal with the main program having ended?

' something like..
Dialog Get Size hWnd TO x&, x&: If x& = 0 Then Exit Function

• Are you using Comm Line [Input] while checking if the device is attached? - This can be a 'Blocking Statement' and that might cause you problems if the main program ends while it's waiting to return.
• Are you explicitly setting the port's CommTimeOuts?

[Michael Mattias]

Could a file opened with Freefile, somehow not get closed? ..

No. If you don't close a disk file, Windows will - when the process ends. (BTW, files are opened using OPEN. FREEFILE is used only to obtain an internal PB handle).

Could Streamin somehow be not processing a message in its callback, and not passing it on and creating a endless loop that I am not aware of? (like a DefFrameProc not used would do to me?)

You can code an endless loop many different ways. You can also test any call in any procedure.

But the easiest way to see if you have an endless loop somewhere is to use TRACE. If it's a procedure, you'll see many, many entries. If you are worried that you may have an endless loop within a procedure, add some labels.. TRACE reports each time a label is encountered

Some similar thing with a statusbar?

Sure, you can create an endless loop with a status bar. Or an edit control. Or a disk file. Or a Memory-mapped file.

Generally endless loops are caused by careless coding. Equally generally, these can only be debugged by a third party (e.g., forum members) if they can actually see (1) the code.

If a control or a dialog or a window that has been destroyed, and some routine try to do something with it cause a program to continue?

Destroying a control or window has absolutely nothing to do with a process ending. However, in all cases(2) you must explictly "do something" when you are notified the control or window is being destroyed... eg, EndDialog or PostQuitMessage.

That is, ending a process is the responsibility of the programmer.


MCM


1 Includes any alternate output device designed for the use of the visually impaired.
2. May not be true with 'DDT' coded programs; the compiler "may" be acting as your momma and cleaning up after you.

[Cliff Nichols]

After days of staring at code, debug, animate, trace any routine I could possibly think of (and a few that should not have any effect, but did it anyways "Grasping at straws") I noticed 1 thing that MCM mentioned and I had forgotten.

TRACE reports each time a label is encountered

I forgot about the labels getting reported nomatter what, so I commented out all my "EXIT FUNCTION" commands before my error checking in each routine, and found nothing but my label that printed (and "magically" my process released), then I went back and uncommented what I just commented, and again my process released as it should.

I don't get it, but it now works, so unless it rears its ugly lil' head again, I will have to chalk this one up to "Ghosts in the machine"

Thanks MCM for that lil' reminder that the label would get logged, even if there is no error to report.

[Cliff Nichols]

Update

Found it!!!!!!!!!!!!
One of my callbacks had a "Exit Function" before my DefWindowProc that I did not notice.
Amazing how anything else worked without trouble, but I guess it depends on the sequence of what Windows calls in what order.

Anyways, thanks to all for their help and input