Dear All,
I am recently (hardly a month) into coding .Net forms in Openedge 10.2A. But I have experience in OE ABL.
In our application the main program (main.w) is an ABL Window. All other programs are called from this ABL Window. This ABL Window has a "WAIT-FOR System.Windows.Forms.Application:Run()".
I have a wrapper (.p) program wrap1.p which contains the following.
DEFINE VARIABLE dotnetFormInv1 AS CLASS dotnetFormInv NO-UNDO.
dotnetFormInv1 = NEW dotnetFormInv().
WAIT-FOR LLKuMoLi1:Show().
This wrap1.p is getting called from main.w.
The question now is how do I delete the instance "dotnetFormInv1" because the "WAIT-FOR LLKuMoLi1:Show()." does not wait there.
In the above structure the destructor of "dotnetFormInv" does not get called.
But if I run the dotnetFormInv.cls directly from the OE Architect then the destructor gets fired.
Could someone let me know if there is a different structure to be followed to acheive the above functionality.
Could someone please let me know.
Thanks much in advance,
Best regards,
Joel W Winston
I am not in the office until October 10th 2012. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.
If you need support from appSolutions, please send your mails to support@app-solutions.com.
If you need Roundtable support, please send mails to :
support-europe@roundtable-tsms.com.
Jeg er væk fra kontoret indtil den 10. oktober, og checker ikke mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.
Hvis du har behov for support, kontakt venligst support@app-solutions.com, så vender vi tilbage så snart det er muligt.
Administrative henvendelser kan ske til : admin@app-solutions.com.
Med venlig hilsen / Regards
Thomas Hansen
appSolutions a/s
Try changing your WAIT-FOR to be something like the below (which is pretty close to what Architect does).
DEFINE VARIABLE dotnetFormInv1 AS CLASS dotnetFormInv NO-UNDO.
dotnetFormInv1 = NEW dotnetFormInv().
WAIT-FOR System.Windows.Forms.Application:Run(dotnetFormInv1).
You might want to take a look at the Primer for GUI for .NET Application Design at http://communities.progress.com/pcom/docs/DOC-16314 .
-- peter
Hello Peter,
Thanks for your suggestion. I tried this and I got the following error message.
System.InvalidOperationException: Starting a second message loop on a single thread is not a valid operation. Use Form.ShowDialog instead.
This may be beacause of the WAIT-FOR System.Windows.Forms.Application:Run() in the main program??
Thanks
Joel
When the Form is started from the ABL window which is already using the WAIT-FOR System.Windows.Forms.Application:Run ()
When you need to know when the Form is closed, subscribe to the FormClosed event.
Hello Mike,
Thank you. Looks like you are puting me in the right direction. I tried this but still the destructor still does not fire. But it fires for the same structure for some other programs of my colleagues. Would there be any property of the form I am failing to set. For the forms for which the destructor is firing there is button and from the button they have the "this-object:dispose" and "this-object:close" statements.
Thanks,
Joel
The destructor will fire when the object is deleted from memory. That's either done from the garbage collector or when you use the DELETE OBJECT statement.
Check if you have any variable somewhere that keeps a reference to the form. This will keep the GC from doing it's work. Also, when the Form has subscribed to an object, the Form will not be GC'ed until that object is deleted.
If you're sure the Form is not needed anymore, it's safe to DELETE OBJECT it.
Vielen dank Mike.
I will try that.
Can a .net form subscribe to an 4GL procedure?
Thanks
Joel
Can a .net form subscribe to an 4GL procedure?
A procedure can subscribe to a class based event. That is what you need here:
oForm:FormClosed:Subscribe ("FormClosedProcedureNameHere", hProcedure) .
A class cannot subscribe to a PUBLISH/SUBSCRIBE Event of a procedure. But that's not needed here.
Thank you Mike that helped.
I am doing the GC myself. Hope that is OK.
Best regards,
Joel