ReleaseForm not releasing the form

[Scott24x7]

I have an odd issue. I have several forms that are not responding to the issuance of the ThisForm.Release() function. I have it on close window and on a specific "exit" button on the form, but when I watch the code step through in the debug, it executes the line, but nothing happens... the form stays in the MAIN form window, and doesn't release.
Any idea what this could be???


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Release does not work directly. The current method (eg click) has to finish first, then the form is released.
Another issue could be a variable holding a form reference. But surely, when you are debugging and single step this does not immediately close the form.

Bye, Olaf.

 

[Mike Lewis]

when I watch the code step through in the debug, it executes the line, but nothing happens

That's correct. [tt]THISFORM.Release[/tt] does not immediately close the form. The rest of the code in the method will continue to execute. The form should then close after the method is finished (and any methods that call it).

The likely causes of your problem are (i) a dangling object reference; (ii) some code elsewhere in the method that is preventing the form from closing; (ii) code in the QueryUnload method that is preventing the form from closing.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Thanks, guys, I'll look at this, but it doesn't look like the item ii or iii that Mike mentions. The "dangling object reference", I can only imagine is some problem with goAPP, but for the life of me, Im'm not sure what that would be.
The variable holding a form reference... hmmm possible, but I don't know where I would have done this (it's not done on purpose, that's for sure).
Let me have a look.
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

You don't have to have any such serious problem, even in totally normal circumstances the release() still only causes the form to close after all code has finished. As Mike said, that means the callstack first needs to empty and go up to the READ EVENTS, at least to the DO FORM line, when your form is modal. And then the signal to release the form will cause that windows event.

Bye, Olaf.

 

[Scott24x7]

These aren't modal forms... But it may be related to the new ribbon bar that I implemented at MAIN, since the form is called from a pageframe, (button object inside the pageframe). I'm still working to implement this idea, and since I moved the forms, now none of them will resolve with the ThisForm.Release() where before they would, so I'll have a look at the stack at runtime and see what's there.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

It also doesn't matter whether the form is modal or not, that just changes the situation when the callstack is "empty" and the release event occurs, no more, no less.
Even without the debugger in play, create a new empty project, create a form, add a button, in it's click program two lines: 1. Thisofmr.Release(), 2. Messagebox("Bye!").

Bye, Olaf.

 

[Scott24x7]

Hi Olaf,
I see your point, and I tried your example, so the form doesn't release until the messagebox executes so that all makes sense.

But in my app, I put the release form in a close button (close form button in the upper right corner, to mimic the kind of windows behavior).
When I watch the trace, it goes through to READ EVENTS, but the window still doesn't close.
I don't see any other code that needs to execute, but the windows aren't being released that are called from the ribbon bar...

I just walked it through with the debugger on and the call stack resolves with code executed on the "Thisform.Destroy()" event, and there is no code left. It then passes to READ EVENTS, but the form persists.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Good, or not good. That means you do have a dangling reference. Something still points to the form and it stays open.
How do you start the form in your code?

Bye, Olaf.

 

[Scott24x7]

Yeah, it's confusing, I don't feel like there is anything different that I'm doing. But one thing I can see is forms (like our Splash and About screens) aren't based on the form classes.
The form classes have been there a long time, but I added ribbon bars, and ribbon at the MAIN form.
In the Ribbon in MAIN form (Page1 of the pageframe) I launch a form with the "DO FORM <formname> WITH (some position parameters top, left)
That form runs.
If I click the close button on top right of form (which is a custom container button with code that executes on the form, basically checks if editing/adding and if so says "This is unsaved, do you want to save it"? If you say yes, it does a TABLEUPDATE and then a ThisForm.Release()

If No, it just does
ThisForm.Release()

There is also a "Done" button on the form that can be pressed to signify you're done with the form (legacy button). It just has the code ThisForm.Release()

Pressing either of those just leaves the form there...
I'm looking at the stack, and the debug, but debug just sits there on the READ EVENTS clause, as it should do, but the form stays open... argggg


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

the stack proves you're at the point the release event signaled is executed. But dangling reference now menas this release can be stopped and rejected, because something holds a form reference. That's the point we're at now. We know it's not your debugging and not fully executing code that stops the release, we know something is dangling.

And thanks for providing the DO FORM, that means there is no central variable you initially had to hold a form reference. But during form execution, whenever you pass THISFORM (wasn't there a thread about form interoparation?) and store that reference, there you have your reference keeping the form alive. The dangling state the form is in means releasing such references would end the form and finally make it vanish, Within IDE a CLEAR ALL typically clears such dangling forms or other objects, the releasehas run unsuccessful.

Bye, Olaf.

 

[Scott24x7]

Thanks Olaf... any idea where I should be looking then. I'm kind of at a loss...

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Hey Olaf,
I *think* I got it. It seems the dangling reference is in the ribbon bar, which I have also imbedded into the forms (so app has one ribbon bar, and the forms have their own, different bar configurations). In the INIT at the MAIN form level of the ribbon I have goAPP.RibbonBar = THIS. I had the same code at the form level, and taking that out seems to have resolved it... At least for now, and as far as I can tell, maybe there is a new problem on the other side of this, but it seems progress is being made, and I can see how one call from main and one from the form to the same goAPP reference could be causing it to hang...

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Hi Scott,

well, I already thought it was about thise references we talked about earlier ("wasn't there a thread about form interoparation?")
If a form makes itself known to another form by passing THISFORM, and if that reference is stored for future reference (no pun intended), then this means you have such a place of some other object holding a reference.

VFPs final object release (not onlky of forms) works with a reference counter geting back to 0. The form.release process runs through destroy, as you saw, but still the reference count not getting back to 0 keeps the visual part alive as "zombie". So when your form pases THIS to another form (or ribbon), then it should also be able to untie from the ribbon to be able to release.

This all is easier, when you really implement a form handler, and don't call into this.realease but into goApp.formhandler.releaseform(THIS). The form handler then could use this reference to work on the form itself (eg finally calling its release for you) but also use it's hwnd as key to a collection. If you also let a form handler do the management of keeping all references as a central "authority for that, references always can be retreived for temporal usage in LOCAL vars anywhere you need them, for interop/callback etc.

As far as I remember I suggested that, but you wanted to keep the changes at a minimum with the single reference instead of building up a handler. It really pays, as you see.

Bye, Olaf.

 

[Scott24x7]

Hi Olaf,
Yeah, we did discuss, and this arena, especially with goAPP and form handlers, is foreign to me, so I make little steps, and sometimes you just understand after making your mistakes right?
So I'm starting to get it little by little, but this level of OOP design and function is still a bit of a mystery to me. On the plus side, as I make these mistakes, the solutions sometimes become clearer. At the moment, I'm not sure if it is clearer, the concepts you mention are pretty advanced, and my skill level isn't quite there yet, but trying hard.
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[jhbelalc]

Try:
[pre]RELEASE WINDOWS cNameOfWindow[/pre]

cNameOfWindow is the name of the window file (the .scx -.sct) and for better results the same name in properties.

It worked for me.

 

[Koen Piller]

Scott,

to find out about your stack:

=ASTACKINFO(m.aStk)
For m.i = Alen(m.aStk, 1) - 1 To 1 Step - 1
* I named each element to make it easier to understand (jjh)
	m.lcCurPrg  = m.aStk(m.i, 2)
	m.lcModule  = m.aStk(m.i, 3)
	m.lcSource  = m.aStk(m.i, 4)
	m.lcModLine = Transform(m.aStk(m.i, 5))
	m.lcSrcCode = m.aStk(m.i, 6)
Endfor

Regards,

Koen