I'm using Visual Basic 2008 (VB.NET) and I have an old control which have some buttons on it. These buttons can not be pressed without actual click and the control have no event or API for that. The control is something like the picture below which has multiple objects and buttons as a single control which controls inside the control can be changed dynamically according to some conditions but at a fixed place and this is why I think simulating a click that I said is the best way in my opinion:(The actual control is completely different that the picture below. It's only a sample)
I can click on the button by doing these steps:
Collecting all controls positions on my form
Moving the control in order to put the button exactly at the left top of the form
MyControl.Left = -43
MyControl.Top = -6
Moving form exactly to the center of the screen
Me.Location = New Point(Screen.PrimaryScreen.WorkingArea.Width / 2 - 1, Screen.PrimaryScreen.WorkingArea.Height / 2 - 1)
Simulating a click action at the center of the screen
Moving back controls to their positions that I got in the first step
It can be done that way but it's not reliable and it might not be user friendly for my program customers.
I want to ask if there are any better method to do that like simulating a click event on a position on the form itself (so I don't have to move controls and do other steps)?
Of course I feel I must tell you that simulating a mouse click in order to programmatically click a button is not a very good idea. Many things can go wrong with this method (The form could move, making your mouse click on the wrong location; Form could be minimized, or another form could be on top of it, etc)
That said, it is possible, so take a look at this article that contains the code to simulate a mouse click.
http://www.developerfusion.com/code/276/simulating-mouse-events/
Once again, please consider doing this a different way. Iterate through the controls in the user control until you find the button you want and use button.performclick. Or you can call the function that the button.click event calls yourself, if it is public
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.
I am working with a Visual Basic.NET project in Visual Studio 2017 (.NET Framework 4.6.1)
I am using a Listbox which is associated with a BindingSource.
The Listbox is contained within one pane of a SplitterControl.
I also have a TabControl is located within the other pane of the SplitterControl. This control contains child data associated with the items in the ListBox and is refreshed when the ListBox is clicked and an item is subsequently selected in the ListBox. The Click event refreshes a Treeview, which then populates the TabControl with data if/when (1) a tree node is clicked and (2) appropriate data is retrieved for that node.
The Listbox Click event works fine while clicking different items consecutively within the Listbox only.
However, once the mouse clicks in the TabControl (in the other pane of the SplitterControl), then once the initial Listbox is clicked, the Click event doesn’t fire.
I have researched this issue (on StackOverFlow as well as other forums) and suggestions have basically revolved around the idea that the Click event could be forced by calling the routine set up as the Click event handler (e.g., myListBox_Click).
I have tried this, but the problem is that I am losing the current SelectedIndex / SelectedValue.
To illustrate by reproducing the issue within the app where I am encountering the problem:
The app in question (note the Listbox highlighted by the red arrow - Screenshot 1):
Screenshot 1
Upon startup of the app, the Listbox behaves as it should, if the user clicks nowhere else, only selecting various items within the Listbox. The TabControl (initial tab shown is always the Profile tab) is refreshed accordingly.
However, if at any point, the mouse is clicked in the TabControl (e.g., to select another tab, note Screenshot 2)
Screenshot 2
Now, when the user clicks on another item in the Listbox, the wrong item is selected (shown in Screenshot 3):
Screenshot 3
The Click event is now being forced via a call to MyListBox_Click within the TabControl_Leave event; my thinking was that this was the appropriate place to put the subroutine call. My reasoning was that when the Listbox was clicked in this scenario, the first event to fire (as far as I could tell) was the TabControl_Leave event.
Not surprisingly, if the same item in the Listbox (in this example scenario, Allegheny) is subsequently clicked, than the result is what should have happened on the previous click (that the SelectedValue is correct, as seen in Screenshot 4):
Screenshot 4
Of course, this is correct, since the last click occurred while the Listbox was already the active control.
I have tried several approaches such as (1) using a global variable to store the current index/value and retrieving it, and (2) using the Tag property of the TabControl to store and retrieve the same value. This has either worked inconsistently or not at all because of the order in which the control events fire.
Hopefully, I've been clear enough on the nature of my problem/issue.
Anyone have any ideas on what my next approach could be? Any ideas/insights/suggestions will, of course, be greatly appreciated.
Thanks in advance,
Chris Fleetwood
Software Developer
North Carolina Partnership for Children (SmartStart)
I have my form with a menu bar and space underneath to display my controls. One of the buttons in my menu bar is suppose to be a print button that prints a graph that's currently in a User Control I display in the form. If the graph was on the form in the print button's eventhandler I could just simply call
graph.printing.print(true)
which isn't going to work in my case since the graph is in the control and not the form.
How do I communicate with a User Control from the containing form and access or pass its variables when needed? I also have a status bar on the bottom of the form which would also need to get updated from the User Control, but I'll be able to deal with that if I got help with just this one part. Please bear in mind, I also have another User Control I'm going to add to the form which will also contain a graph which will need the same treatment as the other graph on the first control when the print button is pressed. I plan on swapping these two out so I have one form displaying one control at a time.
I got this idea from this answer: https://stackoverflow.com/a/18191630/2567273 but after further research I can't find anyone asking about the actual communication process between a form and the control it contains.
I think this answer is close to what I'm looking for, but I think it's leading me down the path to using panels instead of User Controls.
After typing this I noticed the closest answer to my question may be this, but that question has the child raising events and the parent responding while I have the parent raising the event and the parent has to get information from the child.
One way to think about this is Roles. Presumably you built this UserControl to handle the management of the data related to the graphs. As such you can think of them in the Role of a Graphs Specialist . Once you do that, printing them is actually just one more thing it should perhaps do.
The form on the other hand, is not special just because it happens to get receive the command from the user to print. Its role in this might simply to be to know which usercontrol to contact and which method to invoke:
Sub PrintGraphMenuClick....
Select Case something ' determinant as to which UC to contact
Case operation.Foo
ucFoo.PrintGraph
Case operation.Bar
ucBar.PrintGraph
Other menu options like Clear, NewGraph, Save and whatever else there is somewhat the same way. The Form's Role here may be to receive the command from the user and pass it along to the right control, invoking the correct right method and passing the correct parameters - that is not a trivial task.
Of course, rather than a MainMenu, the usercontols could alternatively implement a ContextMenu and even receive those commands directly.
Very often offloading an operation to something else results in so many properties, filenames, streams etc having to be moved from here to there that it becomes burdensome. In this case it is not like the MainForm has some special ability regarding printers that the UserControl cannot handle.
There is only one right solution:
1) Add an event to your user control.
2) Raise the event when the particular "thing" happens in the user control.
3) Attach a handler to the event in Form code.
4) Add code to update the bottom bar in the event handler.
I had a question about Dialogs in VB.NET. I am working on a point of sale program, and at one point during a sale, I have a few windows that pop up. For example, a user will go into a sale that is window A. In window A, they have the option of entering products, etc., and if they choose a 'repair' product, it opens window B, allowing them to choose options. In window B, there is a button that pops up window C that allows them to attach products TO the repair. My issue is with window B opening window C.
Because I open window B as a Dialog (in order to check if DialogResult.OK is true), any window I open with B is non-touchable, as B is a Dialog and requires attention before going to any other windows/forms.
My question is - is there any way to still use a dialog, but allow for manipulating other open forms while the dialog is up, and if not, what would be the best way to check if the user selected OK, or cancelled out of the window?
The only solution I can think of right now would be to open window C as a dialogue as well (it's actually a UserControl, and I'm still trying to find where in the code it's actually getting openned/called), or to create a variable that is passed in to the form, and then passed back out when it's closed, that basically sets a flag to either continue or cancel...
Any advice/ideas??
If I were to explain this using code, this answer would be very long, so instead I'm going to give you a high level overview.
.Show() vs .ShowDialog()
The link below will take you off to Microsofts website to explain the technical differences between these two. However in laymans terms, .ShowDialog() will create the form where it is the only window allowed to have focus in the application. Forms that are called in this instance are hierarchical, in that if you open them in order of 1,2,4,3 then they must be closed in the 3,4,2,1 order. Forms that are opened with just .Show() can be focused at any time.
How to: Display Modal and Modeless Windows Forms
Form.FormBorderStyle property
This property controls how the OS will display the window. The different options under this selection changes the way the window behaves. Depending on the options that are chosen you can make a window that only has a close button on it, or it may not even have a title bar at all. Setting this option to None will take away all controls of the form and only leave you with the Me.ClientArea to work with. When you want a completely custom GUI, this is how you do it but you have to implement your own controls for everything, closing the form, size handles, the ability to move the form on the screen, etc...
Form.FormBorderStyle Property
Passing data between forms
When someone asks how to pass data back and forth between forms, they are usually talking about modeless forms that were created using .Show(). The most common thing I see on SO is to use the tag property of an object (a form is an object that has this property too) to pass data back and forth. While I won't say this is a bad practice, I will recommend creating public properties on your forms. These can be set from a separate form and you can perform additional actions when setting the values (be careful though, this way of doing things isn't thread safe). If you are using a Modeless form as though it were a Modal form, then you can simply override the .Dispose property to return a value or you can create a method named DialogResult that will return the value you need. The caveat to using a DialogResult or similar method is that if the form has been disposed then you can't access the value you wanted to return.
You can use myNewForm.Show(Me) for the Window you want to be shown as a dialog. This will show myNewForm as a child of the current form, but lets you interact with the current form.
Ok so this maybe a simple/silly question but I don't know so here goes:
In access let's say I want to have a frame control, so I click the option group button and add it to the desgin surface. However, I am not wanting to use this as a option group with radio button selection, instead I would like to add text boxes instead the frame, so that when I reference the frame, it references every control instead of it, hence the text boxes, cbo boxes, etc.....just as it would if they were radio option selections.
So can you do this?
I want whatever controls I add inside the frame to be easily referenced (i.e. make all controls visible just by using frameExample.visible = true) so that I can build my own tab control groupings.....
can this be done?
Thanks!
EDIT:
What I am trying to accomplish is having a form that includes a collection of controls (input controls - cbo boxes, text boxes, etc), that serve as the Main record information. These are saved to a table via an INSERT statement on button_click because this form is unbound.
Next I have 8 categories that are relative per each main record (and data that goes along with it). Each of these categories could have a sub form area and a button click that bring it's relative form into the sub form area. These sub forms would be unbound as well as I would just save data via SQL statement. So i know I could accomplish this by running the insert statement from the parent form, on the main collection control's data that would create the KeyID number, then run a SQL statement that would turn around and load that KeyID number right back onto the page in a hidden text box.
Then when I click one of the sub forms and load its relative collection of controls, I could then save that data along with KeyID for each of these sub-forms/tables.
SO......
I was wondering if instead you could define these controls as a collection so that you could hide and make visible all the ones you need on button clicks and avoid the need for additional forms (subs). I know that if a user enters data into a text box, and then somewhere along the way that box becomes hidden, the data still exists in it and still ends up in the SQL statement....
So I want all these controls to exist on the same form, but I thought what is I could encapsulate them into a frame like an option group, then I could call the frame and all the relative controls would be called up (made visible) as needed.
Sorry for the long explanation but I thought it would help.
I do not think you can do it with an Option Group, but what you are describing is pretty much a subform, yesno?
Some examples of hiding the tab control from an app that went live in March 1998:
Tab driven by transparent command buttons over labels styled to look like colored command buttons:
Same approach, more buttons:
In this case, fake colored command buttons don't drive the tab, but insted show/hide the tab and a subform. In this case, the tab is actually driven by the listbox:
A view of when the tab is hidden and the subform revealed. The listbox drives navigation within the subform, which has a visible tab on it:
So, there's a lot that can be done without showing the tab control.