This is a winform question in .net.
In a MDI form, if I open several children forms, for some forms, if they are not activated (if you overlap them with the activate one, they are not up to front. Only the activate form is up to front.), clicking them don't bring them to front. This is even true if I click controls on them, such as a textbox. The textbox gets focus and you can intput things, but that form is still not activated.
Interestingly enough, this is not the case for all the children forms I created. Some forms behave correctly but others don't. Did I do something wrong?
I think the correct behavior is that, everytime I click a form, bring it up to front.
Thank you for any suggestion.
childForm.MdiParent = Me
childForm.WindowState = FormWindowState.Maximized
childForm.Show()
childForm.Focus()
try this
childForm.ShowDialog(Me)
Related
I have a Winform that has 2 datagridviews (parent-child relationship) that I fill with data on form load. I then have a textbox that I put a date in and use it to filter the main grid's databindingSource (which appropriately filter the child grid).
Everything was working fine as I developed the form until it seem to not want to refresh the form... portions of the form would simply be white until I actually move the form around on the screen making it repainted. Now that the form is painted I select different rows in the grid with either the mouse or the navigationsource's next/back arrows. The grid again doesn't refresh unless I move the form around the screen again (grab the title bar and move it around).
I have code in the child form's RowPrePaint method which shouldn't affect anything right? That's the only method that could remotely distrupt the form painting.
I'm going to start reversing my steps but I don't think there is anything that's going to make sense.
Does any of this sound familiar?
I believe the problem is that I had conflicting code in the DataGridView_RowsAdded and the DataGridView_RowPrePaint. I've also switched from the DataGridView_RowPrePaint to DataGridView_RowStateChanged as suggested here: RowsAdded Event in DataGridView only firing for first 2 rows
Thanks for the suggestions
I´ve been working for some time on a good OSK solution for my WPF apps, that are running on a tablet. But it´s hard working with the OSK.exe and tabtip.exe, because of several bugs, strange behaviour and no standardized solution to this ordinary problem.
What I (probably) need is a custom textbox control, which inherits from System.Windows.Controls.TextBox, and overrides some methods.
The simple requirements for this textbox should be:
1. When a user clicks in a textfield, the tabtip.exe (or alike) keyboard should pop up at the bottom of the screen (default).
2. If the keyboard pops up on top of the textbox, the contentframe should scroll so that the textbox is visible.
3. When the textbox loses focus, the keyboard should close automatically, except if the user clicks on another textbox.
This seems like pretty standard behaviour right? Well I´ve looked a long time for solutions (there is no standard microsoft way which is kind of weird), and as said I´ve tried making my own but with no luck. For example, sometimes when I try to kill the process, it fails. When I click the close button in the upperright corner on the keyboard, like 5-6-7 times, it closes. The behaviour from PC to tablet is not consistent. The ScrollViewer.ScrollToVerticalOffset(x); sometimes doesent work on a tablet, and so on.
So does any of you know a good solution to this common problem?
I have a winforms MDI app where a window that is a "child" of the MDI form pops up a dialog, like this:
AddPartsForm partsForm = new AddPartsForm( );
partsForm.StartPosition = FormStartPosition.CenterParent;
DialogResult result = partsForm.ShowDialog( this );
As you can see, I have attempted both to center the dialog within its parent, and to establish who the parent is. This generally works. The dialog itself is a form with a dropdown list from which to select something that fills a grid on the same form. Occasionally, the loading of the grid takes up to ten seconds.
During the loading, I am careful not to move my mouse or click on anything. Yet, every so often (but not always) when the grid loads, the dialog "disappears" behind the form that called it. I can find it in the system tray, but I want this not to happen. There must be a parent/child or owner/child convention that most everyone uses and I have missed, because I do not see this kind of behavior in most software that I use.
I like how MsgBox stops all further processing until it's clicked but I don't like how it pops that little msgbox in the middle of the screen. Is there a way to do something like a msgbox but keep it on my Form (which is always in view) so I can go ahead and click a button on the form instead of having to bring the little msgbox window on top of windows that may be covering it.
I use the msgbox to inform me that a certain situation has happened, which I manually fix and when I'm done I click the MsgBox to continue processing. It'd be nice to have this button right on the form.
which I then have bring to the front if there is a window covering it
That shouldn't happen, but can happen if you display the message box from a thread in your program. The window has the desktop as the parent and has no Z-order relationship with the windows in your user interface. And yes, can easily disappear behind the window of another app, including your own.
There's a MessageBoxOptions option that isn't exposed in Winforms, MB_TOPMOST, which ensures the window is top-most. You'd use it like this:
MessageBox.Show("text", "caption", MessageBoxButtons.OK,
MessageBoxIcon.Information, MessageBoxDefaultButton.Button1,
(MessageBoxOptions)0x40000); // use MB_TOPMOST
But by far the best thing to do is to display the message box on your UI thread. Use Control.Invoke() to do so. That way the other windows of your app are disabled, no way for the user to not notice the box.
Still one problem with this, the user won't expect the box to show up since it is shown asynchronously from anything she does. Which means the box can easily get dismissed by accident when the user just happened to press the Enter or Space key. Or clicked at just the wrong spot. Nothing much you can do about that.
Centering the box in your main window is technically possible, but fugly to do. Check this answer.
Do you mean that the form shall exchange its contents with a message plus an OK button?
This would be similar to the way a text mode interface typically works.
You can make it happen by adding a disabled panel or UserControl with message and button topmost on the form and enable it when you wish to alert the user. However, I am puzzled how to implement the blocking behavior similar to MessageBox.Show() and Dialog.Show().
I have several Wpf pages in my project, these pages have different forms and ui control indide theme. The image below shows the mainWindow and there are two button.
I want to show a specific page when I click on + or Edit button using the Frame control which is highlighted.
apparenatly this woks:
Page1 me = new Page1();
mainFrame.Content = me;
But it has an IE navigation sound and a toolbar appears after going to page2.
any better way to show diffrent pages and not using a frame?
You may want to convert the Page into a UserControl. You can then put that control inside some other container, such as a Grid. You'll have to manually swap out the pages in the container when navigating, but it looks like you're doing that anyway.
The purpose of the Frame control is to allow navigation. If you don't want navigation, then don't use Frame. You can turn off the navigation toolbar, but that won't actually disable navigation - there are mouse buttons and keyboard shortcuts for navigating back.
If you just want to host a UI element without navigation, use something simpler, like a Border element - put the content in its Child property. You can change the Child as many times as you like at runtime.
I was able to set the frame control's NavigationUIVisibility to Hidden. This solved the problem for me. I am using Visual Studio 2010 though so it might not be applicable to older VS versions.
Ian Griffiths, what you suggest increases the workload on the developer substantially. And you are stepping outside of the underlying paradigm of XAML.
In my case I'm developing a game application and have chosen WPF as the UI platform as much as possible. For me that means a intro screen, character select, etc. The purpose of Pages is to encapsulate the navigational need of such an application.
I suspect your downvote is due to your statement "If you don't want navigation...". Upon re-reading the original posters question I see he does want navigation, he just wants it on his own terms. I would have voted you down too. YotaXP's solution neglects the issues with using a User Control, particularly if it may contain other User Controls. It looks like Chris Calvert came up with an actual solution to the poster's issue within the parameters of the problem.
I would be curios if I could override the navigation hotkeys and such within the existing paragimn but that's properly in its own thread.