I'm open a modal dialog box using the next code:
call screen 0010 starting at 15 1.
However it disables the main window to continue working.
It's posible to call a modal dialog box and enable the main window to work while it's opened?
The very nature of a modal window is that it blocks the application until it is closed. The opposite would be an amodal dialog, and no, you can't have an amodal modal window. What you can do:
CALL FUNCTION 'Z_FUNCTION_WITH_DIALOG' STARTING NEW TASK 'FOOBAR' - this will start an additional external session (as long as the user has not exceeded the session limit).
Use the class CL_DGUI_DIALOGBOX_CONTAINER to produce an amodal window. Be aware that you can't use screens (dynpros) inside this container. Check the report RSDEMO_DIALOGBOX_CONTROL for some example coding.
Related
I have created my MS Access Program but I have multiple monitors and so do the other people who will be using the program.
Just so you know my forms are popup style, have no borders or record selectors and I am guessing this is where my issue comes in.
I would like to know if there is a way to ensure that when a user opens a form, the form will only open within the MS Access Window/Canvas on the active monitor?
I would also like to know if there is a way for my application to automatically adjust according to the users screen resolution?
As an example my Forms open perfectly when I am using the application on my main screen which has a resolution of 3840 x 2160 but if I open the application on my second screen which has a resolution of 1920 x 1080 the forms that open subsequently, such as the user form, then opens on the main screen so small that no one can read or see it.
Application is on Right monitor and User Form is Open on Left (Main) Monitor
The code I have used for the OnOpen Event is below:
Private Sub Form_Open(Cancel As Integer)
Dim Right As Integer, Down As Integer
Right = Screen.ActiveForm.WindowLeft
Down = Screen.ActiveForm.WindowTop
DoCmd.MoveSize Right, Down
End Sub
This was obtained from some research but I cant seem to bind everything to the Application Window/Canvas.
Thank you.
Well, if you only ever have one window open at one time, then you can do this with ease.
Remember, today most applications are SPA (what we call single page applications). We don't use (nor have) very often a main applcation window, and THEN a child window. For one, they tend to not be touch friendly, and it is VERY hard to move a window around with touch.
but, even desktop browsers even use some "kind" of tabbed interface. And so do most desktop applications. And by tabbed - I don't necessary mean across the top. This access screen shows a tab system from the left side:
So, Access now has a option to use tabbed interface.
And if you :
do NOT use pop windows.
Set access to use tabbed interface, eg this:
Then un-check the display tabs.
If you do above, then you WILL NEVER EVER see the access background window.
You see this:
However, keep this in mind:
The form you launch will re-size to the main size of the Access window - not the other way around.
All forms can't be popup
You are "SPA" like applcation.
So, most accounting and most desktop applications now work this way. And WHEN you launch a form, the window does not re-size tot he form, but remains the current applcation window size.
So, without ANY specials code, you can 100% hide the access background window.
And if you re-size the access application window, then the form will re-size to fill out the current form.
This might look quite bad in some cases - such as this:
Now for above, I on purpose made the form background green - just to PROVE and show that that Access background window NEVER will display with above options.
So, the main issue here?
You can 100% hide the access background window. And you can now do this WITHOUT specials code. Just a few settings.
On startup, you can hide the ribbon - or build a custom one - again your choice.
But, your forms MUST NOT be popup forms anymore.
So, hiding the access background window is very easy - it then becomes a question of form size - size forms re-size to application window size - not the other way around.
On the other hand, if you adopt a tabbed interface (accross the top or left side), then your main window is always in display, and you are in effect swapping out the form (a sub form) for display of that given form. You can write your own code, or use a new navigation form - which does this for you).
If you need to launch separate windows, then you could launch them as popup from this main form - but that main form will of course always hide the access background if you follow above.
If you wish to hide the ribbon, then on your main form - load event, you can add this code:
DoCmd.ShowToolbar "Ribbon", acToolbarNo
So, your main form (which hides access background) could be tabbed inteface (SPA) or it could be a launcher form, and each option clicked on could launch a form as popup - which can be dragged anywhere on your computer - including to the 2nd monitor if you wish.
So, either forms stay always in the main applcation window - but never see the background. Or you use above, and launch forms as popup.
We have a VB.Net Application with a Main form that should always be visible. However, we want to be able to display a succession of two dialog windows where we can close the first dialog as the second one appears. However, when doing that, the Main form gets sent behind whatever other applications are open and does not re-appear until the second dialog window closes.
We can correct this issue by keeping the first dialog window open behind the second one, but it’s not ideal. What are we doing incorrectly?
Try using dialog1.owner = mainform
I need to create a form where AlwaysOnTop = True when the browser is visible. This creates some sort over "overlay". The logic works like this:
The program checks which window is active.
If the active windows is a certain process, my form will initialize the TopMost utility, and be the active window itself.
When the certain process is not the active window anymore, my form will disappear.
How I did it:
My program checks if a browser is the active window, if so: the form gets topmost and the program stops checking what the active window is. (because my topmost form is the active window now).
Now the program needs to check what the window under my form is, the second active window.
If it's not the browser anymore, the form needs to hide, and the program will check what the active window is again.
I already completed the function that checks what the first active window is,
I'm stuck on getting the function that checks what the second active window is.
I'm not sure that there's such as thing as a "Second active window" - its either active or its not.
Why don't your leave you active window checker running after the first step of detecting the browser.
You can detect when the active window is no longer your form and hide your overlay then.
Working in SharePoint 2010, with SharePoint Designer 2010, I have a DispForm to which I've added a DVWP that displays a filtered view of another relative list. The DVWP has a 'New' link which opens the NewForm for that list in a modal dialog, using OpenPopUpPage (http://msdn.microsoft.com/en-us/library/ff410825.aspx).
After 5 - 12 seconds, the blinking cursor disappears from the first control and the focus switches to the 'Close' button. If the user was trying to type and happens to hit the Enter key when the focus switches to the 'Close' button, the background is no longer darkened and the 'Cancel' button no longer works. The form is still displayed on the screen, and the user can 'Save' but the modal never goes away until the page is refreshed.
If the user notices that the modal has lost focus and clicked back on the form, everything works as it should and all is well.
Observations:
When the control/modal loses focus, the 'Close' button does not trigger a 'focusin' event. But, $(document.activeElement).attr("value") displayed in the console shows that it's the active element.
Questions:
Why is the modal losing focus?
Does anyone have a Javascript/jQuery workaround to capture the event and set the focus back where it was?
Alternately, what if I lock the form and wait for this focus-change to complete, then unlock it and set the focus on the first field? Ideas?
You may be having a problem if the DispForm is also a dialog and you open the modal with your script. It sounds like you are getting a "layered" effect. My guess is that the script managing the dialog is interfering with the modal. Have you tried turning off the dialiogs for the list?
Just so I get some points on this site, the affliction was the asynchronous refresh of the first modal. It was taking the focus away from the layered modal.
Thanks JB for the answer!
I figured out the problem: the DVWP was using Auto-Refresh with the Async Update. This was running every 15 secs, taking the focus away from the modal, then not returning it to the last control.
So, we turned of the auto-refresh and used the callback from the modal close to trigger a click on the manual refresh button instead.
What's the correct method, to open up a new dialog so that the user cannot return to the main window until the modal dialog is closed.
A typical modal window is created by the alert() function.
I've tried it like this without success:
.openWindow(null, "chrome://myapp/content/mywindow.xul","mywindow",
"chrome,centerscreen,all,modal",null);
You forgot to mention that you are using nsIWindowWatcher.
For the window to be modal you need to specify which window it needs to be modal to. If the first parameter to your openWindow() call is null then the window watcher won't know which window opened the dialog (which window needs to be suspended until the dialog is closed). In other words:
watcher.openWindow(mainWin, "chrome://myapp/content/mywindow.xul", "mywindow",
"chrome,centerscreen,all,modal", null);
Or simpler:
mainWin.openWindow("chrome://myapp/content/mywindow.xul", "mywindow",
"chrome,centerscreen,all,modal");
See window.openDialog().