ACTIVE-FORM

Posted by Admin on 08-Dec-2009 11:54

bheavican schrieb:

Is there an event I can catch for when ACTIVE-FORM changes?

I'm not aware of any built in functionality.

If you're only using Forms that are inheriting from Progress.Windows.Form it's relatively easy to set up. Do you already have your own common form base class in place (good practice anyway)?

Just add the follwoing you your common form class (let's say it's called YourCompany.Windows.Form):

CLASS YourCompany.Windows.Form INHERITS Progress.Windows.Form:

    METHOD PROTECTED VOID OnActivated (e AS CLASS System.EventArgs):
        SUPER:OnActivated (e) .
        /* Use static method as "session-event handler" */
        YourCompany.Windows.Form:OnActiveFormChanged (THIS-OBJECT) .
    END METHOD.
    METHOD PUBLIC STATIC OnActiveFormChanged (newactiveform AS YourCompany.Windows.Form):
         MESSAGE "The new active Form is" newactiveform:Text 
              VIEW-AS ALERT-BOX.
    END.
END CLASS.

All Forms built in the VisualDesigner should inherit from this class, not from Progress.Windows.Form (the default). You might use Interfaces from your menuing system to enforce using your own base type rather than Progress.Windows.Form.

Posted by bheavican on 08-Dec-2009 11:59

I have a base form that we inherit from. My problem is on the .w side. We have a mixture of .w's and .cls's. The leave/entry events do not fire on a .w if I go from a .w to a .cls back to that .w. We have context on a per window/form basis that needs updated when the window/form is entered. The .net form activated event seems pretty reliable but the .w entry isn't. Any thoughts on what I can do?

Posted by Admin on 08-Dec-2009 12:30

bheavican schrieb:

I have a base form that we inherit from. My problem is on the .w side. We have a mixture of .w's and .cls's. The leave/entry events do not fire on a .w if I go from a .w to a .cls back to that .w. We have context on a per window/form basis that needs updated when the window/form is entered. The .net form activated event seems pretty reliable but the .w entry isn't. Any thoughts on what I can do?

That sounds indeed like an issue. Haven't faced that yet, but I never needed to know so far when a users changes the window. Are you already on 10.2A02? There have been some issues with ABL events in conjunction with .NET Forms fixed in the service packs.

Are you already embedding the ABL windows (.w files) into .NET Forms. Then you'd be getting the Activated event for the embedded .w's and could to really pretty things like adding .NET Toolbars, Ribbons, etc. to the ABL windows.

Posted by bheavican on 08-Dec-2009 12:47

We are on 10.2A02 already. We have over 1000 windows to maintain and we've made the decision to "not" embed our windows in containers. It really seems like a bug to me, but I understand why the .w events aren't firing. Thanks for your help.

Posted by Admin on 08-Dec-2009 13:37

bheavican schrieb:

We have over 1000 windows to maintain and we've made the decision to "not" embed our windows in containers.

For any specific reason (like issues)? I've supported a number of clients already using embedded ABL windows to enhance .w files. So far I've had no issues at all and it's really a great possiblity to stepwise enhance the UI of an existing app as well as preparing the development of new modules using native GUI for .NET.

It really seems like a bug to me, but I understand why the .w events aren't firing. Thanks for your help.

Please let us know the result, when you are going to report this to tech support.

This thread is closed

All Replies