Hello,
We are in the process of updating our existing ABL Windows application to use GUI for .NET. This will be done over a period of time, not all at once. It is possible that we will have an ABL window that is may be called by either another ABL window or a GUI for .NET form.
Is there way for the child window to know what called it (Window or Form)?
Also, we may have a form called by either another form or a window. Is there a way for the Form to know what called it (window or form)?
Thanks,
Dave
I'm interested to know about this too as our company is looking to do the same thing.
we have one .net form that we developed, but the only way to call it from the ABL environment was to make a small stub window (.w) and have it call the .net object. This works but it is a bit kludgy.
Why do you need to know this? Do you need to be able to call back into your parent? Or do you need to "Parent" .NET Forms to ABL windows and vice versa.
IMHO the actual parenting (Owner property of .NET forms) is not behaving as most users expect as it's causing child windows to be minimized when the parent (owner) is minimized.
If you just need a handle/reference of your caller, I suggest you provide two additional constructors for your .NET Form: One with a HANDLE as the Parameter and another one with a System.Windows.Forms.Form as the reference. This way the caller (procedure that created the ABL window or an ABL GUI for .NET Form) can introduce themselves to the called form.
oForm = NEW YourChildForm (THIS-PROCEDURE) or
oForm = NEW YourChildForm (THIS-OBJECT)
In case the Child is an ABL Window procedure, do a similar thing, with two input parameters:
DEFINE INPUT PARAMETER phProcedureParent AS HANDLE NO-UNDO .
DEFINE INPUT PARAMETER poObjectParent AS System.Windows.Forms.Form NO-UNDO .
and then
RUN yourchildwindow.w (THIS-PROCEDURE, ?) . or
RUN yourchildwindow.w (?, THIS-OBJECT) .
[quote user="Ken Ward"]
we have one .net form that we developed, but the only way to call it from the ABL environment was to make a small stub window (.w) and have it call the .net object. This works but it is a bit kludgy.
Can you please explain more why you had to do this? Was this because of your menu system only able to run .w's?
In that case you should consider to update your menu program to be able to DYNAMIC-NEW ABL GUI for .NET Forms.
Our application uses a temp-table to track currently open windows using handles and unique-ids as keys in the temp-table. On a window I would need to know if called from a form not to try and get the unique-id of the calling program (form). I have been using the overload of the constructor to tell if it is called from a window or a form.
On the window side I was hoping to avoid using input parameters, but I will likely have to resort to that.
Thanks for you input.
You can check to see if ACTIVE-FORM is type-of Progress.Windows.IForm during construction of a new .cls, and if it is then ACTIVE-FORM:PROWINHANDLE will be the handle to the .cls/.w that is active as your new .cls is being built.
You can make the same check in a .w before enable_ui as well.
I like that approach.