All,
I have a TabControl in an application that started behaving strangely. Some background...
This program was converted from VB6 to VB .NET 2008, and used to refer to forms using their class names. In other words, I might have a form class called frmFoo. In the code for the program you might see:
frmFoo.Show()
or
frmFoo.UserDefinedProperty = True
During some recent changes, I created variables to represent instances of my forms much like these:
Public MyForm as frmFoo
MyForm = New frmFoo
MyForm.Show()
In doing so, I also removed code from the form's Load event handler and put it in the form's constructor.
When the form loads, or when a document is loaded and should influence the TabControl's selected index, something like the following will not necessarily fire the SelectedIndexChanged event.
MyForm.tbsForm.SelectedIndex = ValueReadFromFile
...or...
MyForm.tbsForm.Tabs(ValueReadFromFile).Select
Sorry to be so wordy, but there's more. If I open the form and look at the TabControl to verify that it's been set properly, everything works like it's supposed to. The misbehaving TabControl is contained within another TabControl, so I have to click the parent TabControl to see it. If I can see it, and run a test, the test always works. If I can't see it, and run a test, the first test I run will not fire the event. ...paging Dr. Heisenberg...
It's almost as if the control has to be initialized first by changing the value or making it visible onscreen...I'm totally lost on this one. It's the most unusual behavior I've ever seen. And everything worked perfectly before I began using variables to represent forms and placed the Load event code into the form constructors.
Can anyone help, or at least put me out of my misery?
SH
-------------------------------------------------------------- Edit #2
I just performed a test after having attempted to eliminate some of the variability in the behavior. But I wanted to confirm the previously-stated behavior.
I opened the program and read a file. This file contained a value that should have triggered the event handler. Without making the control visible, I can change the SelectedIndex property of the tab control without the event firing.
I closed the program down again, and reopened it. This time, selected the parent tab that allowed the child tab (the one whose event I'm concerned with) to become visible. I then selected a different tab in the parent control, meaning that the child control was no longer visible. When I opened the same file as before, it fired the event.
I'm tempted to implement a flag that confirms that the control has been repainted or whether the parent tab has been displayed. I may have to fire the event in code if the flag isn't set.
I want to reiterate that everything worked when the program referred to the forms by their class names and much of the arrangement of controls on the forms was done in the load event. Now the program creates variables and the arrangement of the controls is done in the form's constructor. I'm sure this has something to do with the problem I'm having, but I can't understand how. Any wisdom to share?
MyForm.tbsForm.SelectedIndexChanged = ValueReadFromFile
doesn't make a lot of sense. Is tha trying to assign a handler to the SelectedIndexChanged event? or is ValueReadFromFile the name of the tab?
What you're saying is that you have two tab controls, say, A and B. Tab control B is contained within a tab of A, and unless A has the tab page selected that contains the tab control B, the SelectedIndexChanged event of B will not fire if you change its tab programatically?
In which different ways have you tried to select a tab within the child tab control, and when is this code being executed?
Related
I've taken over a project, which contains some UltraWinGrid controls on some of the forms.
On one of the original forms which has been there since before I took on the project, there is a ContextMenuStrip, which has just one ContextMenuToolstripItem on it, captioned 'Default for Column'.
This ContextMenuStrip is hidden by default, however, when the user right-clicks on the UltraGrid, the ContextMenuStripItem is displayed on the grid (rather than at the top of them form where the ContextMenuStrip is).
I'm trying to replicate this behaviour in a new form that I've added myself, however, after adding the ContextMenuToolstripItem in, I cannot get it to display when right-clicking my grid.
I've put a breakpoint on every subroutine in the in the older forms class, and none of them are triggered when right-clicking it.
Additionally I have also searched the class for DefaultForColumnToolstripMenuItem, and the only place it appears is in the Click event of the ContextMenuToolStripItem itself.
So, how else is it possible to show it when right-clicking the grid? I've copy and pasted the ContextMenuStrip from the old form onto the new form and still nothing occurred.
I'm assuming it's in a property somewhere that I'm missing?
Check for a ContextMenuStrip property on the UltraWinGrid. You can set it in the designer and your context menu will appear on right click without having to deal with the MouseClick handler, checking the mousebutton used, etc.
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.
I have a form that is re-used. That is, instead of creating a new instance of the form each time, the form is kept hidden, and is made visible when needed. (A design I inherited; I presume this was a performance optimization.)
The problem: The second time that the form is used, the focus is on the OK or Cancel button, from the first use of the form.
The user wants the focus to start the way it did the first time the form appears - on the control with lowest tab index.
If there were just one such form, I would hack it: add a line of code hardwired to the desired control.
But there are many such forms, and the visibility logic is in a common base class.
So it would make more sense to do this right, and tell the form to focus on its first (lowest tabindex) control.
Is there an easy way to do so?
(I could iterate through all the controls, but then I have to correctly handle nested controls. Since the GUI has to do this the first time it shows a form, I am hoping there is some method I can call that does it for me.)
(Coded in VB.net, but a C# answer would be fine.)
It is a one-liner, the logic to find the next control is exposed as a method, SelectNextControl(). You should start at the Form object, the one that can never get the focus, and ask it to find the next one in the tabbing order. Which is the child with the lowest TabIndex, whatever value it might have.
So something like this:
public void ShowAgain() {
this.Show();
this.SelectNextControl(this, true, true, true, true);
}
And do consider that a Form object that isn't visible is a rather major resource hog, using up lots of operating system resources for a small convenience. Surely you can also Close/Dispose it and recreate it when needed. YMMV.
You can try to set ActiveControl property before making form visible:
_frm.ActiveControl = null;
This should clear the active control for the form and remove focus from its controls.
I am trying to hide specific columns in an Access 2007 split form through code. I need the form to check certain conditions to see whether it needs to display a column or not. I have code in the form's 'Activate' event to hide the column like this:
txtControl.ColumnHidden = True
This code works in the "Open" event, but if I hide the column on Activate, it won't display these changes until I close the form and open it again. I have tried calling the form's refresh, repaint, and requery methods, but this doesn't work. Please help!
Edit: Ideally, I need this event to occur whenever the focus switches to this form.That's why I'm using the Activate event rather than the Open event.
Try setting it in either the form's Current or Load events. You will also probably need to requery the control after setting that property: Me.TextControl.Requery Current is called every time a form's record is changed, the form is repainted or requeried. Load, as its name suggests, is called once, after the form has opened when the form loads its records. These have always been more reliable for me than using Activate, which really has to do with more the focus of the form, not really what you want.
I've had a problem like this before working in Access 2002. I was able to solve the problem with a subform by setting the subform source object equal to itself and then running the requery.
Me.SubForm.SourceObject = Me.SubForm.SourceObject
Me.SubForm.Requery
See if this technique works for your particular situation.