[RESOLVED] Change Modal Form to Modeless while Beign Displayed

[RobDog888]

I need to display a form as Modal but upon the button click on that form I need it to switch to modaless.

I was thinking displaying it modaless and have the parent form loop until a process is complete but it would be easier to just switch states instead if possible.

Note: This is a VBA UserForm but I can convert any solution to VBA.

Thanks

[iPrank]

Easiest (and possibly only) way is hiding & then showing the form again,
(but it will flicker)

' modal to non-modal
Me.Hide
Me.Show
'
' non-modal to modal
Me.Hide
Me.Show vbModal

But as you want to change it while the form is being displayed (without hiding it ?), I don't think it is possible.

[RobDog888]

I tried something similar to that and was supossed to eliminate the flicker but it didnt work, still flickered but these two methods are very similar and do work just the stupid flicker.

Thanks for the help but if anyone can get it to not flicker I would like to see it

[iPrank]

if anyone can get it to not flicker I would like to see it

Me too.

[jcis]

Just experimenting, this seems to stop the flickering when changing modalness, but it does some kind of flicker when the modal Form2 is loaded Anyway..
The idea: both forms (instances of the same Form) are loaded together, then when the button is pressed in the modal Form2 its unloaded and the modaless Form2 is shown. It seems there is not more flicker al least when changing modalness, because both forms are already loaded and visible.
In Form1:

Private Sub Command1_Click()
    Dim Frm21 As Form2, Frm22 As Form2
 
    Set Frm21 = New Form2
    Set Frm22 = New Form2
    
    Frm21.Left = Me.Left
    Frm21.Top = Me.Top
    Frm22.Left = Me.Left
    Frm22.Top = Me.Top
    
    Frm21.Caption = "Modalness Form"
    Frm22.Caption = "Modal Form"
    
    Set Frm22.FormToShow = Frm21
    
    Frm21.Show
    Frm22.Show vbModal
End Sub

In Form2:

Private mFrmToShow  As Form
 
Public Property Set FormToShow(pFrm As Form)
    Set mFrmToShow = pFrm
End Property
 
Private Sub Command1_Click()
    If Not (mFrmToShow Is Nothing) Then
        mFrmToShow.Left = Me.Left
        mFrmToShow.Top = Me.Top
        Unload Me
    End If
End Sub

[RobDog888]

Hey quite cool but when a user may move an instance of form2 and then changes between modal and modeless the sync positioning of them will need to occur to reduct the incurred flicker. Much better results on my test forms but hopefully my vba userform's code will not interfere.

Let me test it out on my userform now.

[RobDog888]

Just testing some more before I integrate it into the UserForm and tried using the .Move method as its less resource intensive (minimally) and it improved the switching between forms even more.

Option Explicit
 
Private Sub Command1_Click()
    Dim Frm21 As Form2, Frm22 As Form2
 
    Set Frm21 = New Form2
    Set Frm22 = New Form2
    
'    Frm21.Left = Me.Left
'    Frm21.Top = Me.Top
'    Frm22.Left = Me.Left
'    Frm22.Top = Me.Top
    Frm21.Move Me.Left, Me.Top
    Frm22.Move Me.Left, Me.Top
    
    Frm21.Caption = "Modalness Form"
    Frm22.Caption = "Modal Form"
    
    Set Frm22.FormToShow = Frm21
    
    Frm21.Show
    Frm22.Show vbModal
End Sub
 
Option Explicit
 
Private mFrmToShow  As Form
 
Public Property Set FormToShow(pFrm As Form)
    Set mFrmToShow = pFrm
End Property
 
Private Sub Command1_Click()
    If Not (mFrmToShow Is Nothing) Then
'        mFrmToShow.Left = Me.Left
'        mFrmToShow.Top = Me.Top
        mFrmToShow.Move Me.Left, Me.Top
        Unload Me
    End If
End Sub

[jcis]

Found this, seems much better. Example: you want to change Form2 from modal to modalness or vice versa, pass the Hwnd of the Parent Form to MakeModal Function:
In a module

Public Declare Function EnableWindow Lib "user32" (ByVal hwnd As Long, ByVal fEnable As Long) As Long
 
Public Enum MakeAsModal
    Modal = 0
    Modalless = 1
End Enum
 
Public Sub MakeModal(ByRef frmParent As Form, ByVal isModal As MakeAsModal)
    On Error Resume Next
    Dim RetVal As Long
    RetVal = EnableWindow(frmParent.hwnd, isModal)
End Sub

In Form1

Private Sub Command1_Click()
    Form2.Show
End Sub

In Form2

Private Sub Command1_Click()
    MakeModal Form1, Modal
End Sub
 
Private Sub Command2_Click()
    MakeModal Form1, Modalless
End Sub

Edit: It works, but you wont get the typical Flash window and "beep" that VB6 makes when clicking a Form without Focus, not sure about VBA.

[RobDog888]

Thats another good one but unfortunately in my project's VBA UserForm doesnt have a parent or secondary form. Its only a single UserForm.

Also, with the previous example, I have controls on the form that would also need to be updated/sync'd with the other instance just before the switch. Hmm...

[jcis]

This works fine in an UserForm in Excel (using 1 UserForm, Excel App is the Parent)

Private Declare Function EnableWindow Lib "user32" (ByVal hwnd As Long, ByVal fEnable As Long) As Long
 
Private Sub CommandButton1_Click()
    EnableWindow Application.hwnd, 1
End Sub
 
Private Sub CommandButton2_Click()
    EnableWindow Application.hwnd, 0
End Sub

[rami.haddad]

Manually create your modal form by making it a "Always On Top" form. When you want to turn it off remove the "Always On Top"

Public Const SWP_NOMOVE  As Long = &H2
Public Const SWP_NOSIZE  As Long = &H1
Public Const flags  As Long = SWP_NOMOVE Or SWP_NOSIZE
Public Const HWND_TOPMOST  As Long = -1
Public Const HWND_NOTOPMOST  As Long = -2
 
Public Declare Function SetWindowPos Lib "user32.dll" (ByVal hWnd As Long, ByVal hWndInsertAfter As Long, ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
 
Public Sub SetTopMostWindow(lngHwnd As Long, blnTopMost As Boolean)
 
On Error Resume Next
 
If blnTopMost Then
    Call SetWindowPos(lngHwnd, HWND_TOPMOST, 0, 0, 0, 0, flags)
Else
    Call SetWindowPos(lngHwnd, HWND_NOTOPMOST, 0, 0, 0, 0, flags)
End If
 
End Sub

[iPrank]

Manually create your modal form by making it a "Always On Top" form. When you want to turn it off remove the "Always On Top"

Sorry. I disagree.
My users will not like it if my app opens an always-on-top form when they are multitasking.

[RobDog888]

Being an "Always on top" form does not make it modal. The Modal characteristic is important for me to have just as much as changing it to modeless.

[jcis]

Rob, just to be "updated" with this thread, if you have only one UserForm without parent or secondary form then the Application object shouldnt be its Parent? if this is the case, post 10 couldnt be a solution?
The only VBA I know is part of MSExcel or MSWord but as you said "no parent" maybe you are doing something different.

[RobDog888]

I must have misread post 10 last night, well actually this morning. So I will try it again but the UserForm is in Outlook and I could use FindWindow to get the apps handle so I'll try to tweak it for Outlook.

[iPrank]

I tried to change DS_MODALFRAME style, (and other experiments on style bits) but that didn't work.

I've taken a look at Dialog Box Topics(Visual C++ Programmer's Guide)
From there I found that (in VC++), modal and non-nodal dialog boxes cre created by 2 different function.

To create a modal dialog box, call either of the two public constructors declared inCDialog. Next, call the dialog object’sDoModal member function to display the dialog box and manage interaction with it until the user chooses OK or Cancel. This management by DoModal is what makes the dialog box modal. For modal dialog boxes, DoModal loads the dialog resource.

For a modeless dialog box, you must provide your own public constructor in your dialog class. To create a modeless dialog box, call your public constructor and then call the dialog object’sCreate member function to load the dialog resource. You can call Create either during or after the constructor call. If the dialog resource has the property WS_VISIBLE, the dialog box appears immediately. If not, you must call itsShowWindow member function

And,

Life Cycle of a Dialog Box

During the life cycle of a dialog box, the user invokes the dialog box, typically inside a command handler that creates and initializes the dialog object, the user interacts with the dialog box, and the dialog box closes.

For modal dialog boxes, your handler gathers any data the user entered once the dialog box closes. Since the dialog object exists after its dialog window has closed, you can simply use the member variables of your dialog class to extract the data.

For modeless dialog boxes, you may often extract data from the dialog object while the dialog box is still visible. At some point, the dialog object is destroyed; when this happens depends on your code.

So, I guess, in case of VB, IUnknown or some other culprit calls the DoModal method.

Destroying the Dialog Box

Modal dialog boxes are normally created on the stack frame and destroyed when the function that created them ends. The dialog object’s destructor is called when the object goes out of scope.

Modeless dialog boxes are normally created and owned by a parent view or frame window — the application’s main frame window or a document frame window. The defaultOnClose handler callsDestroyWindow, which destroys the dialog-box window. If the dialog box stands alone, with no pointers to it or other special ownership semantics, you should overridePostNcDestroy to destroy the C++ dialog object. You should also overrideOnCancel and call DestroyWindow from within it. If not, the owner of the dialog box should destroy the C++ object when it is no longer necessary.

So, I think, unless we can find a way to exit from the function, from where VB called DoModal (or similar) method, we can't make the form non-modal properly.

[iPrank]

...and I tried to remove WS_DISABLED from the parent/caller form. But that didn't work either.

[RobDog888]

Maybe because I havent had my morning coffee yet but for the way I need my Outlook UserForm to work, post 8 and 10 dont work for me. The UserForm is still modal and not releasing the process to the parent to continue on.

I think for practical purposes I can live with the minor flicker from the hide/show method. But I would like to see if its possible still. [/color]

[iPrank]

The modal form will not release the control until it is destroyed.(See the middle MSDN quote).

(I GUESS) When we use .Hide, only the WINDOW (dialog box ?) gets destroyed. The dialog object (Form object ?) still remains intact. That's why control goes back to the caller form.

For modal dialog boxes, your handler gathers any data the user entered once the dialog box closes. Since the dialog object exists after its dialog window has closed, you can simply use the member variables of your dialog class to extract the data.

[RobDog888]

Ah, ok.

* Going for first cup of coffee now *

[iPrank]

It is time to call Moeur for help.

[RobDog888]

Or Joacim Andersson. Havent seen him online yet today

[Joacim Andersson]

You rang

I don't know how much help I can be to this thread since I'm currently sitting on a hotel room with a computer that doesn't have VB or Outlook installed, so I can't test anything.

With that excuse out of the way, here goes: First of all, as you've already discussed, there is no way you can switch from a (true) modal to a modeless behaviour without first hiding the Form. The implementation in VB is a bit different from how it works with an MFC application which stores the dialogs as resources, but the basic idea is the same. The message pump for the modal Form keeps looping and doesn't return until the Form is hidden or destroyed. None of the style bits for a Form is changed when you show it modally. I'm not 100% sure about UserForms in VBA but they should work in a simular fashion as the VB Forms does.

You can simulate a modal Form in the fashion jcis showed by disabling the caller window. However that will only make the Form look modal to the user, the code still runs in the parent and as I understood it your main concern was that the code should not continue until the UserForm was switched to modeless. The other idea jcis had about loading two instances of your Form, one modeless and one modal, would also work however as you've mentioned there would be a problem if the user moves the modal Form. The only way to get around that would be to subclass the modal Form and check for the WM_MOVE and WM_MOVING messages and move your modeless Form accordingly. However that might seem like a bit of a overkill just to get rid of some flickering.

Another idea that hit me, which I can't test since I currently don't have VB, would be to call LockWindowUpdate on the desktop window... Maybe (I don't have a clue) that will prevent the screen from being redrawn during the few milliseconds it takes to hide and show your Form.

Call LockWindowUpdate(GetDesktopWindow)
Me.Hide
Me.Show
Call LockWindowUpdate(0) 'Unlock it. You do [b]not[/b] want to keep the desktop locked :)

[RobDog888]

Yes, I had tried that earlier but on the VBA UserForms handle and its about the best I can get. The LockWindowUpdate passing the GetDesktopWindow does not flicker the captionbar but the client area of the userform does go al white and then back for an effect that seems worse then the previous method.

I think for the most part using the lockwindowupdate passing the forms handle and then hiding and reshowing is the best solution for your $.

Thanks Guys for all your help and Thanks Joacim for seeing the Bat Signal.

[Joacim Andersson]

The LockWindowUpdate passing the GetDesktopWindow does not flicker the captionbar but the client area of the userform does go al white and then back

I was afraid something like that would happen since only the non-client area is painted directly on the desktop while the Form itself is responsible for the client area. But as I said, I had no way of testing my suggestion. Unfortunatly you can only lock one window at the time.

[RobDog888]

I used Spy++ and had found that a VBA UserForm contains two windows. A main form window and a nested client area window. So maybe thats why the client area of the form would not lock for the update.

I do appreciate the help though