Within VB.NET Visual Studio 2013
I have an mdi application with several forms. Only one form is open at a given time, then while the user enters amounts by typing in the control, the form is recalculating itself constantly via code.
I also have buttons above (on the mdiform) to open modal dialogs to enter certain information; the information entered is somewhat long, but at the end what I need from the dialog is the result of certain calculation.
That number (the result) should be shown on the opened form after the user close the modal dialog; but it is not happening unless I press the enter key so the form is again recalculated.
I am looking for a way that the form recalculate when the user close the dialog.
I tried everything at my disposal, "Activate", "a public sub", "raise an event", and many others, but the form is not recalculating, what happens is that the cursor is there on the last control the user works in.
The only way to see those changes is reloading the form, but it is not elegant.
Any help will be highly appreciated.
PS. I have looked everywhere about how to do it, but seems I am looking on a haystack
Please need help badly.
ariel
Related
I'm working on a fairly complex Access Database, trying to build forms with custom buttons for working with records. I'm using list boxes to display and navigate through records and all fields for existing records are disabled unless the user presses an edit button. The problem I'm having is that if I press the Edit or Add New button, enabling all of the fields, and then try to change the selection in a combo box, it does not update on the first try.
If I edit a text box first then the combo boxes work fine.
I've determined that the control's beforeUpdate and afterUpdate events are not firing on the first try but the action triggers the form_Dirty event and then it works as expected. I tried setting Me.Dirty = True with the Edit button and that solved the problem but it causes problems with some of my other code and it seems like an unnecessary workaround if only I understood the actual cause of the problem. It also works as expected if I leave the Combo Box unbound, but I am trying to build a template that doesn't require too much work to build new forms off of and I would rather not go that route.
It must have something to do with some bit of code I'm using because I can start a basic form and the combo boxes work fine.
I've started a basic test form and am adding code from my template form bit by bit until the problem arises, but it's a tedious process. Any help would be appreciated.
What am I missing? Is there some way of getting the Combo Box events to fire before the form is dirty?
UPDATE:
I have templates for a basic form, a form with a single subform, and a form with multiple subs in a tab control.
After some more testing I discovered that this problem does not apply to the basic form which has no subforms. This template uses similar code to the others for new, edit, cancel, save and delete buttons and for preventing accidental changes, preventing Form_unload during an edit and so on. The main difference I can think of off the top of my head is that the templates with subforms use class modules and collections to hold various data and pass it between the main form and subforms. Not sure if or how this might relate to combo box functionality.
I built most of this last winter then got too busy over the summer to work on it. Just now picking it up again and I'm having to re-learn a lot of the details of how my code works.
you can try to use Me.CboName.Requery in your After Update event.
I figured it out. I was calling a procedure with a form refresh in it from the Form_Dirty event and for whatever reason the refresh at exactly the wrong time was causing the combo box Before_Update and After_Update events to be skipped and the combo box value to not change. It was also causing text entered into a textbox to overwrite existing text on the first keystroke.
I am programming a little application (an overgrown macro really) in Visual Basic for Applications in Office 365. What it does is:
Displays one window that has a few input fields.
Once I fill out those fields with data I can press a button on the form and a summary in a nice graphical form is displayed in a second window (a second form is displayed using UserForm2.show).
The second user form can be updated with new data by typing in updated text in first form and updating the second form by pressing a button on the first form (in the form of UserForm2.TextField1.Text = UserForm1.Label1.Text.
Both forms are modeless so the user can work in Outlook whilst the forms are running.
All works fine except one caveat:
Both forms are not visible on the Windows Taskbar, in the Task Manager, but most importantly they are not visible as separate windows to teleconferencing software we are using. And this is the macro's sole purpose.
Question: Is it possible to make the entire macro (or just UserForm2) run as if it was a separate application, so it appears in the Task Bar as a separate window, and not an internal form running inside Outlook?
The idea is not to run it independently of Outlook (or Excel), but to make them visible to external programs.
I tried a few options available on the Internet, but none of them work, and honestly I do not know where to begin, or how to circumvent it if it is not possible to do directly within the available API. Can you advise?
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.
I'm developing a VB.net windows application and I have some issues with the keyboard input.
My application has different forms and I'm showing and hidding them with the user interaction. One of the inputs comes from the keyboard, and here is where I have a problem.
When I hide a form and show the next one, most of the times the new-shown form does not receive the keyboard input until I click somewhere on it.
I assume that the problem is that the new form I'm showing is not the "selected application" for windows until the user interacts with it by clicking on it, but I don't know how to set this "property" by code.
I tried with focus and select on the whole form (Me.select/focus) and in some form's control (me.lbl_xxx.select/focus), but I did not get any result.
Can anyone explain me how to control which application/form gets the keyboard input on windows?
Thanks
David
You can't really interact with a label so the input focus won't be set properly.
Focussing a specific textbox on your form on the other hand should just work fine.
We have a "Core" system that we use to run the business and there are about 15-18 people using it at any one time. The program is written in VB.NET and has about 165 forms.
The way it works is when the user runs the program he/she is prompted to log in and if the login is successful a "Main" form is displayed with a number of menus (Customers, Suppliers...). From there they can click on the menus which open another form on top of the "Main" (the "Main" form needs to be visible in the background because it displays information that is relevant to the users while they are in other screens)
The issue we are having is that if the users have other programs open while using the "Core" system (Outlook, Word, Chrome, anything really) and switch to another program and then back to the system, it only displays the "Main" form and any other forms open on top disappear. The way we get around this is by switching back to the other programs they have open and clicking on the minimise button in the top right corner of the window until all the other programs are minimised, which only leaves the "Core" system visible. However this is becoming a nuisance to all the users (including myself and the other developer) and we really need to sort this issue out in order to keep out staff happy :)
I would appreciate any advice or pointers in the right direction which will help us solve this issue and please feel free to ask if you need any more information.
It seems you are creating the ChildForm from the MainForm but the ChildForm itself is showing itself with Me.ShowDialog(). What you should probably try is showing the form from the MainForm and passing the MainForm in as the parent. This should keep the form tied to it's parent and on top. For example:
childForm.showDialog(Me)
Where Me is the MainForm. This is the documentation for that method.
This is the important part:
Owner Type: System.Windows.Forms.IWin32Window
Any object that implements IWin32Window that represents the top-level window that will own the modal dialog box.
Does that make sense?
Changing code to show dialog will change behavior of your code little bit, like your main from execution will hold till you close child form
But you can you use only show as child (not dialog)
childForm.show (Me)
This will not change anything except whenever you click on main form it will display its entire children on it.