I want to make a desktop item manager program using vb.net.
I hope to create a form there and use the menus etc. to make the desktop icons work.
You want to set the form to always be behind the other windows. Like a widget.
How to do this?
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.
The overall goal is to be able to access a pop-up keyboard through an application that I am making in MFC.
I have created a dialog box with an empty text field. I would like to be able to click the empty field and have an onscreen keyboard to enter in the data field.
Is there list of functions or tutorials that anyone can provide me with to be able to perform this function? Ultimate I will be making the keyboard from scratch, so any guidance would be useful.
My first thoughts (I might be wrong someone might correct me if i am wrong.)
1)Create your Keyboard Ui in an MFC DLL and export the KeyBoard Functions like LaunchKB(Int screenx,int screeny) and CloseKB()
functions.
2)I would subClass CEdit and CRichedit such that when the edit control gains or loses focus it would call LaunchKB() function with windows ScreenX coordinates where the keyboard has to be displayed or CloseKB().
3) A callback function registered to dll ,which would get called for every click on the keyboard with characters clicked and these characters are to be displayed in the edit control.
This is just my thought ,there may be better ways to implement as well.
I'm running with an 8.5.3 UP1 server and I have a need to have many dialog boxes (for confirmation purposes) for a whole bunch of "action buttons" on an xpage. The code for these dialog boxes is almost exactly the same with the exception of the confirmation message being different and the client-side JS function they are calling if the Yes button is selected.
Since I really hate repeating code over and over, I was wondering if it is at all possible to put a xe:dialog control within a repeat control and specify the message and function call from an array of values? I know I can't compute the ID of the dialog control and without that I'm not sure how I would reference the dialog to open and close it.
Any ideas? Thanks
Yes, this is possible.
Make sure that you specify that the dialog box's property for keepComponents is set to False. You don;t have to do anything special for opening or closing the dialog box, just use whatever ID you give the dialog box in you client-side action to open the dialog box in the repeat such as XSP.openDialog('#{id:myDialog}')
The XPages renderer will automatically calculate the correct ID names for you.
Am writing a VB.Net app written in VS2010. This displays some reports in several forms. (Am using Crystal Reports though this is incidental to the problem). The user needs to be able to check these, then confirm if he wishes to run the update process or abort.
My first idea was to ask the user to reply using a messagebox. But of course this is modal, so the user cannot browse through the reports.
I thought of other options but each seems to have problems:
- export the reports as PDFs, then display report in external Adobe Reader Window using System.Diagnostics.Process.Start("AcroRd32.exe", filename). This seems messy.
- create a non-modal message box or equivalent. This loses any concept of program flow, so am unconvinced by this
What ideas do you have please?
You should already be using a form to display the report(s). Put all the reports on the same form with scroll bars enabled and add a button to that form for the user to 'Update Process'.
You may come up with a better display based on how many reports you want the user to look at - like a drop down at the top with list of reports in it OR a radio button list on the left with reports listed etc.