[RESOLVED] vbRichClient vbModeless "form events" are never fired

[pekko]

When form is shown as vbModeless it's "form events" are newer fired,
when form is shown as vbModal work as expected.

'modMain.bas
Option Explicit

Public New_c As New cConstructor, Cairo As cCairo
Public fMain As New cfMain

Sub Main()
    Set Cairo = New_c.Cairo
    fMain.Form.Show
    Cairo.WidgetForms.EnterMessageLoop
End Sub


'cfMain.cls
Option Explicit

Public WithEvents Form As cWidgetForm

Private Sub Class_Initialize()
    Set Form = Cairo.WidgetForms.Create(vbSizable, "Main", True, 800, 600, True)
End Sub
Private Sub Form_Click()
    Debug.Print Form.Caption, "Form_Click"
    Dim fChild As New cfChild
    fChild.Form.Show vbModeless
End Sub


'cfChild.cls
Option Explicit

Public WithEvents Form As cWidgetForm

Private Sub Class_Initialize()
    Set Form = Cairo.WidgetForms.Create(vbSizable, "Tools", True, 400, 300, True)
End Sub
Private Sub Form_Click()
    Debug.Print Form.Caption, "Form_Click"
End Sub

[Schmidt]

When form is shown as vbModeless it's "form events" are newer fired,
when form is shown as vbModal work as expected.

Yep - that's as expected - since only in "Modal Mode", your fChild-Class
(which is the one you placed the Tool-Windows Event-Sinks in) remains alive.

In Modeless-Mode you immediately leave the Main-Forms Click-Event -
and thus the fChild-ClassInstance goes out of scope as well (since you
defined the fChild-Variable at this Procedures Scope).

 
'cfMain.cls
Option Explicit

Public WithEvents Form As cWidgetForm

Private Sub Class_Initialize()
    Set Form = Cairo.WidgetForms.Create(vbSizable, "Main", True, 800, 600, True)
End Sub
Private Sub Form_Click()
    Debug.Print Form.Caption, "Form_Click"
    Dim fChild As New cfChild
    fChild.Form.Show vbModeless
End Sub

So, if your goal is, to handle a Tool-Window exclusively from withing cfMain,
then the Code would need to be changed as below:

 Option Explicit 'modMain.bas
 
Public fMain As New cfMain

Sub Main()
    fMain.Form.Show
    Cairo.WidgetForms.EnterMessageLoop
End Sub

Option Explicit 'cfMain.cls 

Public WithEvents Form As cWidgetForm
Private fChild As New cfChild '<- define the Child-Form at cfMain-Class-Level for correct Modeless-behaviour

Private Sub Class_Initialize()
    Set Form = Cairo.WidgetForms.Create(vbSizable, "Main", True, 800, 600, True)
End Sub

Private Sub Form_Click()
    Debug.Print Form.Caption, "Form_Click"
    fChild.Show vbModeless, Me
End Sub

Option Explicit 'cfChild.cls
 
Public WithEvents Form As cWidgetForm

'introduce your own Show-Method, to allow for repeated Tool-Window-Instance-Showing from the Main-Form
Public Sub Show(Optional ByVal Modal As FormShowConstants, Optional OwnerForm As Object)
  If Form Is Nothing Then Set Form = Cairo.WidgetForms.Create(vbSizable, "Tools", True, 400, 300, True)
     Form.Show Modal, OwnerForm
End Sub

Private Sub Form_Click()
    Debug.Print Form.Caption, "Form_Click"
End Sub

Private Sub Form_Unload(Cancel As Integer)
    'destroy also the Form-Instance in this case, to have a "ReCreate-Flag" for our Show-Method above
    Set Form = Nothing
End Sub

...to ensure the expected behaviour...

The RichClient-Form-Engine is behaving "more strict" with regards to
the Form-Class-Prototypes (and their instances) ... so, normal rules for
VB-ClassInstance-Scope will apply (no "globally undestroyable" Form-
Instances exist automatically, unless you define them in this way
(as you e.g. did for fMain: globally and with 'New' in a *.bas-Module).

If your Child- or Tool-Windows are "possessed by" - or usable with only one
Form - then define these ChildWindows at this concrete Forms Level as Private-Vars...

And in case you need to share a certain ToolWindow among more than one
Parent-Window - then better to define its appropriate Instance-Variable
at global scope in a *.bas.

HTH

Olaf

[pekko]

Yes indeed, that helped a lot, thanks.

Sorry to bother you again but I discovered some extra "weird" things.
- order of the events is not same as native vb forms, is that on purpose? If not whether the order to change in future releases?
- there is some extra paint events (not bothering me)

native vb
Main          Form_Load
Main          Form_Initialize
Main          Form_Activate
Main          Form_GotFocus
Main          Form_Paint
Main          Form_Click        <- form1 clicked
Tools         Form_Load
Tools         Form_Initialize
Main          Form_LostFocus
Main          Form_Deactivate
Tools         Form_Activate
Tools         Form_GotFocus
Tools         Form_Paint
Tools         Form_LostFocus
Tools         Form_Deactivate
Main          Form_Activate     <- form1 activated
Main          Form_GotFocus
Main          Form_QueryUnload  <- form1 close button clicked
Tools         Form_QueryUnload
Tools         Form_Unload
Main          Form_Unload
Main          Form_Terminate
Tools         Form_Terminate

vbRichClient
Main          Class_Initialize
Main          Form_Activate
Main          Form_GotFocus
Main          Form_Paint
Main          Form_Paint
Main          Form_Load
Main          Form_Paint
Main          Form_Paint
Main          Form_Paint
Main          Form_Click        <- form1 clicked
Tools         Class_Initialize
Main          Form_DeActivate
Tools         Form_Activate
Tools         Form_GotFocus
Tools         Form_Paint
Tools         Form_Paint
Tools         Form_Load
Tools         Form_Paint
Tools         Form_Paint
Tools         Form_Paint
Tools         Form_DeActivate
Main          Form_Activate     <- form1 activated
Main          Form_GotFocus
Main          Form_QueryUnload  <- form1 close button clicked
Main          Form_Unload
Main          Class_Terminate
Tools         Class_Terminate

[Schmidt]

Yes indeed, that helped a lot, thanks.

Sorry to bother you again but I discovered some extra "weird" things.
- order of the events is not same as native vb forms, is that on purpose?

Sure - not each and everything has to be exactly as it behaves in the
older Form-Engine.

For example - what always bothered me with VBs native Forms was their
Activate-Events - these Events behave differently now in the RC5 - meaning that
they are raised "more often" - whenever a Form gets activated/deactivated, always -
you can rely on that (which you couldn't in case of native VB-Forms).

Also the behaviour you see with the Unload-Events of a ToolWindow, which
are not raised when you (indirectly) close a Tool-Window (which you attached
to a ParentOwner-Window beforehand) by closing its ParentOwner...

In that case no Unload-Events in the "attached" Tool-Windows are raised by default,
since you made your intentions clear on their ParentOwner-Window already -
if you want to cancel the Unload-Process, then cancel it in the Parent (and only there).

If you are badly in need of these Events, then you can influence the current
behaviour by explicitely calling:

...fChild.Form.Unload
...fMyOtherTool.Form.Unload
...etc.

in the Main-Forms Unload-Event - if you don't, then these Windows will be cleaned
up "silently" anyways (with regard to the Widgets they potentially contain).

Olaf

[pekko]

If you are badly in need of these Events, then you can influence the current
behaviour by explicitely calling:

...fChild.Form.Unload
...fMyOtherTool.Form.Unload
...etc.

in the Main-Forms Unload-Event - if you don't, then these Windows will be cleaned
up "silently" anyways (with regard to the Widgets they potentially contain).

Olaf

Good to know, thanks again for helping me.