Solved Open a form as dialog with no borders. Is it possible ? (1 Viewer)

[smig]

I open a form from a function (It has to be a function to be run from an .OnDblClick event)
I want the form to be opened and halt the remaining code from running.
This form should have no borders.
If I open the form in acWindowNormal the form will look as I expect but code will continue to run.
If I open the form in acDialog mode code will halt, but the form will show it's borders.

How can I get what I want ?

 

[Ranman256]

in form properties, (other tab) set
POPUP =true
MODAL =TRUE

 

[smig]

in form properties, (other tab) set
POPUP =true
MODAL =TRUE

It is
Still does not act as

 

[smig]

I want it to look like this

But if I open it in acDialog mode it will look like this

 

[CJ_London]

change the form border style property to thin or none

 

[isladogs]

Setting popup & modal = True is not the same as using acDialog. Each has a different purpose

Using acDialog, even if you set the form border to none, you will still get the title bar.
As a test, I've just tried it with the Access application interface hidden... title bar still visible
If it helps, you can remove the form caption & control box leaving an empty title bar

But...AFAIK, it is impossible to get rid of that in acDialog mode.

 

[smig]

change the form border style property to thin or none

It set to none,
as you can see in the first picture I posted

 

[smig]

Setting popup & modal = True is not the same as using acDialog. Each has a different purpose

Using acDialog, even if you set the form border to none, you will still get the title bar.
As a test, I've just tried it with the Access application interface hidden... title bar still visible
If it helps, you can remove the form caption & control box leaving an empty title bar

But...AFAIK, it is impossible to get rid of that in acDialog mode.

This is what happen, as you can see in pic. 2
The form's border was set to none, and opening it in acDialog mode showed the border and an empty title bar, with no controls

My question is how can load the form with no border and still prevent the code from continue running ?

 

[isladogs]

Actually you still had the close button
Anyway, yes I realise that's what you want to do. AFAIK you can't do so.

 

[MajP]

My question is how can load the form with no border and still prevent the code from continue running ?

Why do you have to stop code execution. Unlikely you do not need to stop code execution. Just do it differently.

 

[CJ_London]

It set to none,
as you can see in the first picture I posted

appreciate that is what you wanted, but not clear you had set the border property.

So have you tried opening without specifying acdialog? just set popup and modal to true

 

[The_Doc_Man]

I have done a cursory web search for this but am finding limited information. It is a property of the form to find the window handle (.hwnd) so that if you wanted to do something special with the form's containing window, you could. IF you could find the right API. I have a reference book that might have something but I have to warn you that I think Windows (not Access) is going to get in the way of some of this. I will get back to you if I find something in my reference books. But the odds of controlling the window to that level are not high.

 

[CJ_London]

perhaps try this from another direction

DoCmd.OpenForm "myform"
    Do
 
        DoEvents
 
    Loop Until Not Application.CurrentProject.AllForms("myform").IsLoaded
MsgBox "code execution resumed"

 

[The_Doc_Man]

I'm back. After reading through my Win32API books, here is your problem. Whether you are creating a dialog box or an input box or a message box or new full-blown data entry form, you are always creating a child window for this form-like object. You HAVE to create a child window because under the Windows operating system, any code or activities associated with the window's content can get CPU time ONLY if they are represented by a child process of Access associated with the window. It is basically a CPU resource scheduling requirement. Creating a child window means that you have to abide by the WINDOWS requirements for that child. (One case where you CAN'T evade paying child support!)

There are certain features that are created in a child window. If you were to create the window yourself through a Win32API call to CreateWindowEx, you could specify that it had a thin border and no features in the title bar (and thus could also specify "no title bar" if you wanted.) I check for this next fact carefully: There does not appear to be a function to MODIFY the features displayed and extant in a newly created window. You have to create the window to initially have (or not have) the features that you want. Once it is created, it has the features it has (and lacks the features it doesn't have) for the lifetime of the window.

However, you aren't the one creating the window. Access is doing that based on some internal routine that we cannot see. There is no direct interface to what Access actually uses. Therefore, from an Access app, the only way to customize your message box is to custom-build it using only WinAPI calls. Is it doable? Yes. Is it easy? Not really. And while I understand it, I wouldn't want to have to do it. If you are not an experienced Windows app programmer, this might not be in your wheelhouse.

REFERENCE: Win32 Programmer's Reference, Vol 1., Microsoft Press, 1993. Chapter 1, Window Management. 1.1.5.4, Window Borders; 1.1.5.5, Nonclient-Area Components.

 

[MajP]

I assume you just need to capture the close event of the pop up form and then do something with those two values in the textbox. I would not use a timer. This is assumes without ACDIALOG you can achieve the aesthetics you want.

Private WithEvents PopUpForm As Access.Form

Private Sub Command0_Click()
  DoCmd.OpenForm "form2"
  Set PopUpForm = Forms("form2")
  PopUpForm.OnClose = "[Event Procedure]"
End Sub

Private Sub PopUpForm_Close()
 'capture the closing of the pop up form.
  MsgBox PopUpForm.txt1 & " " & PopUpForm.txt2
End Sub

 

[smig]

Actually you still had the close button
Anyway, yes I realise that's what you want to do. AFAIK you can't do so.

No, it's a button I put there. Look at pic 1

 

[smig]

Why do you have to stop code execution. Unlikely you do not need to stop code execution. Just do it differently.

I need to do some tests after I close the form.
If I can't do it this way I'll find another way

 

[smig]

appreciate that is what you wanted, but not clear you had set the border property.

So have you tried opening without specifying acdialog? just set popup and modal to true

I did.
Not working

 

[isladogs]

OK but the point is...as everyone has reiterated since my last post, it can't be done.
More to the point why is it so important that you do so...

 

[smig]

I'm back. After reading through my Win32API books, here is your problem. Whether you are creating a dialog box or an input box or a message box or new full-blown data entry form, you are always creating a child window for this form-like object. You HAVE to create a child window because under the Windows operating system, any code or activities associated with the window's content can get CPU time ONLY if they are represented by a child process of Access associated with the window. It is basically a CPU resource scheduling requirement. Creating a child window means that you have to abide by the WINDOWS requirements for that child. (One case where you CAN'T evade paying child support!)

There are certain features that are created in a child window. If you were to create the window yourself through a Win32API call to CreateWindowEx, you could specify that it had a thin border and no features in the title bar (and thus could also specify "no title bar" if you wanted.) I check for this next fact carefully: There does not appear to be a function to MODIFY the features displayed and extant in a newly created window. You have to create the window to initially have (or not have) the features that you want. Once it is created, it has the features it has (and lacks the features it doesn't have) for the lifetime of the window.

However, you aren't the one creating the window. Access is doing that based on some internal routine that we cannot see. There is no direct interface to what Access actually uses. Therefore, from an Access app, the only way to customize your message box is to custom-build it using only WinAPI calls. Is it doable? Yes. Is it easy? Not really. And while I understand it, I wouldn't want to have to do it. If you are not an experienced Windows app programmer, this might not be in your wheelhouse.

REFERENCE: Win32 Programmer's Reference, Vol 1., Microsoft Press, 1993. Chapter 1, Window Management. 1.1.5.4, Window Borders; 1.1.5.5, Nonclient-Area Components.

Thanks a lot
This seems to be too complex.
I'll try to find a simpler solution, in Access