I have a simple WinForm whose only function is to display a message passed to it. The message is passed as a string and is displayed in a textbox. It is set to be a FixedToolWindow (and no matter how else I set it I get the same behavior in the end).
The form is called with:
PswCoordFailDisplay coord1 = new PswCoordFailDisplay(inputString);
coord1.Show();
Here are two screenshots: top is of the designer; bottom is how it is actually painted.
This is part of a fairly complicated application with about 10 other WinForms. They all act like they're supposed to, except this one.
The changes from design are:
the Form's dimensions change
the textbox changes to occupy the entire width of the form (possibly in response to the size of the text that fills it -- although ScrollBars is set to Both)
the Close button changes its text to "OK" and migrates to the bottom right
the form's Title is gone
the X-closer is different
when I turn ControlBox to False, the X-closer appears regardless, and in the same form as in the bottom example
I pretty much take all the defaults that a WinForm provides when creating the WinForm, except for a couple of items that shouldn't make this kind of difference.
What on earth is happening? I mean, it still works fine, but it's not what the design calls for!
If you pay close attention to the pictured screenshots presented in the question, you will notice that the bottom one shows a MessageBox, not the intended WinForm. As commenters T McKeown and Grant Winney pointed out, there is no way for the elements of the form to go that far off the rails unless the form was coded that way. Since it wasn't coded that way, the expected form is NOT being called. There is a very superficial resemblance, of course, which accounted for my confusion.
If I had showed the complete calling code, a sharp eye would have seen this quickly:
switch (opRes.OpResult)
{
case OperationResult.Result.Succeeded :
MessageBox.Show("Password coordination succeeded.");
LoadUser();
break;
case OperationResult.Result.PartialSuccess :
MessageBox.Show(String.Format("Password coordination partially succeeded: {0}{1}", Environment.NewLine, opRes.Notation));
LoadUser();
break;
default :
MessageBox.Show("Password coordination failed.");
PswCoordFailDisplay coord1 = new PswCoordFailDisplay(opRes.Notation);
coord1.Show();
break;
}
As you can clearly see, with a "partial success" control would be passed to the second case in the switch statement, not the default. The second case was supposed to be coded with the new WinForm, but I forgot to do it! And so there you see the problem:
READ YOUR DARNED CODE BEFORE POSTING YOUR PROBLEM ON STACKOVERFLOW!
Less embarrassment that way.
ETA: Also, if I had posted the above code in my question, as #Rockster suggested, someone would have noticed it immediately, perhaps saving a step or two.
Related
I've hit a frustrating issue with a software project I'm working on. I've got help set up on various forms such that if I press F1, the application's CHM file is opened.
I want it to always open to the topic related to the current form, however it currently opens to a different location depending on what part of the form is in focus. If some fields are in focus, it opens to the top of the first page of the help document; and if other fields are in focus it will open, correctly, to the page and heading related to the current form.
I have the following designer code for the various forms, and I'm only setting HelpKeyword on the form itself, not any of the form's controls.
this.helpProvider.HelpNamespace = #"Path\To\ChmFile.chm";
this.helpProvider.SetHelpKeyword(this, "TopicName.htm#heading_name");
this.helpProvider.SetHelpNavigator(this, System.Windows.Forms.HelpNavigator.Topic);
From experimentation, I've determined that items with either SetShowHelp(false) or Enabled = false are the only ones that show the correct chm help location. This applies when pressing F1 with them in focus (if they can hold focus), or pressing on them with the "what's this" help cursor.
As an example:
If focus is on the main dialog's first control (a TextBox which has a HelpString, which implicitly sets ShowHelp) and I press F1, I'll get sent to the overall application help page (undesired behaviour).
If focus is on a main dialog TextBox which does not have an associated help string, and I press F1, I'm shown the Dialogs help page, at the heading for the main dialog (desired behaviour).
The only workaround I've found for this so far is to set both HelpTopic and HelpNavigator on every control with a HelpString, but this is very heavy-handed and difficult to maintain.
Clarification
I am intentionally using both the "What's this?" help and the F1 help on the same forms. I will not accept a solution that says to disable "what's this" help for all controls on my form in order to allow the F1 help to work. It is a requirement for this application that interactive controls have a help tooltip, and that each dialog has a help section in the help document.
If there is no way to get these two help features to work together nicely, I will accept an effective workaround that does not sacrifice maintainability as my above workaround does.
It was only after your clarification that I was able to fully understand your question and reproduce the problem. This behavior was not known to me before.
Same undesired behaviour using Visual Studio 2019 on Windows 10 PC - it does not matter if it is coded in the Form_Load event or with the help of the IDE (Integrated Development Environment) in the designer code.
After some hours of experimenting (with the reproduced problem) I hopefully narrowed it down without fully knowing the real reason.
I have done the following steps and thoughts - FYI - experimentally (see special notes in the list below):
The default value of the HelpNavigator enumeration is AssociateIndex. If you accidentally set SetShowHelp = True and a required property is missing, the call to the Index tab may fail, corrupt something and goes to the CHM's home page topic. If you don't have an index tab in your CHM, another problem arises.
I deleted or renamed the file hh.dat several tines to reset all (!) CHM windows on my system to their default settings. Windows will create a new version of hh.dat when you next open any .chm file. You'd find hh.dat at C:\Users\%username%\AppData\Roaming\Microsoft\HTML Help. BUT - - no success with the existing problem in the first test phase.
For some more test only (code is not required later) I have tried if the Form3_HelpRequested is triggered. BUT - that did not work in the first test phase.
private void Form1_HelpRequested(object sender, HelpEventArgs hlpevent)
{
// do whatever you're gonna do here
DialogResult dr = MessageBox.Show("HelpRequested on Form1 was fired!\n\nOpen CHM help?","Test case", MessageBoxButtons.YesNo);
switch (dr)
{
case DialogResult.Yes:
// FALSE will also open any associated help file
hlpevent.Handled = false;
break;
case DialogResult.No:
// TRUE will prevent windows from also opening any associated help file
hlpevent.Handled = true;
break;
}
Last as a hard step I deleted the HelpProvider component, have inserted this again and set all properties correctly a second time. NOW - it is working for me. Controls with the property ShowHelp=True now show the assigned topic and controls with the property ShowHelp=False now show the help topic of the form as expected.
You know - this can be a complex step and should be done in a test environment first. Make sure that all properties are set correctly and that the topic is accessible in the CHM via HelpKeyword.
// Tell the HelpProvider what controls to provide help for, and what the help string is.
this.helpProvider1.SetShowHelp(this.cityTextBox, true);
this.helpProvider1.SetHelpNavigator(this.cityTextBox, HelpNavigator.Topic); // make sure to set "Topic"
this.helpProvider1.SetHelpKeyword(this.cityTextBox, #"/Garden/flowers.htm");
this.helpProvider1.SetHelpString(this.cityTextBox, "Enter the city here.");
After giving the city textbox focus and F1 the help viewer window is shown. Using the "What's this" ? button in a second step is resulting in:
tl;dr
The definition of the properties via designer code or program code is more a decision based on personal preferences. I myself prefer to set values in the program code rather than via the controls properties window of Visual Studio.
If you add here all the properties of the controls for the help functionality as code, you can easily comment out for fixing problems. In a form with many controls, it is easier to save parts of the code externally and insert them again later. But as I said - everybody likes it different.
// set F1 help topic for first form
private void Form1_Load(object sender, EventArgs e)
{
helpProvider1.SetHelpNavigator(this, HelpNavigator.Topic);
helpProvider1.SetHelpKeyword(this, #"/HTMLHelp_Examples/Jump_to_anchor.htm#SecondAnchor");
}
BTW - the "What's this?" help for large programs means a high effort and in my experience it is used less and less in help authoring (CHM's). This kind of help has a long history from the times of Visual Basic 6, for example. Today you often find only one help topic for a form or a dialog in which the single controls are explained. The problem you describe then does not appear at all.
FYI - in earlier days a ALIAS and MAP files was required and maybe used today by TopicId. The purpose of the two files is to ease the coordination between developer and help author. The mapping file links an ID to the map number - typically this can be easily created by the developer and passed to the help author. Then the help author creates an alias file linking the IDs to the topic names.
Creating Context-Sensitive Help for Applications
Where to specify topic id in c# windows application
I'm trying to set the cursor in an open document, but it doesn't show. I can see that the line is "marked" and I can "navigate" the lines, but the cursor is not shown, and thus I'm not able to write anything. Also it seems like the document doesn't really fully load, since guidelines and the navigationmap is not shown either.
Which makes me believe that the focus isn't being set completely inside the document.
I have confirmed that the focus indeed is not set in the document in the window, since If I have the output window focused before, it's still focused after the window.Activate() method has been called.
I've used the common way of opening the document through ProjectItem.Open(Constants.vsViewKindCode), activating it, and using the TextSelection.GotoLine(1,false) method.
This correctly shows the document and sets the line correctly, but I have to manually click inside the document for the cursor to appear.
The code I have:
Window window = projItem.Open(Constants.vsViewKindCode);
window.Activate(); <----- this does not focus the window.
TextSelection textSelection = window.Document.Selection as TextSelection;
textSelection.GotoLine(1, false);
I want to not have to manually click inside the document for it to load completely and for me to be able to write in it.
Hope someone can help me.
Oh well, another issue I had to solve by myself... Two for two. I guess people don't know that much in here like I'd hoped. Oh well.
Anywho, I discovered that if you use DTE.ItemOperations.OpenFile(path); and nothing else,
the file will receive focus correctly, just like it should have when you use .Activate().
Sorry for asking such a basic question, but I just can't figure it out. I'm trying to display a status window that just says "Uninstalling prior versions" while the program runs so the user has some idea what's going on. So I created a C# form, added a label and do a window.show(). Here's what the form looks like in design mode:
And yet here's what displays:
I added a second label and a button to make sure that the text of my label wasn't some odd color or something that was causing the problem and they don't appear either.
What's going on here? This should be so simple. I've done this hundreds of times and never seen this behavior.
TaW said in this comment:
You can call Refresh() before starting the long-running work.
Refresh() was just what I needed!
I can't get a form to remain on top, in .net
I have checked How to make form always on top in Application and the answer there mentions form1.TopLevel = true; and I've checked How to make a window always stay on top in .Net? and it says Form.ActiveForm.TopMost so i've tried Form.ActiveForm.TopMost = true; and this.TopMost = true;
private void Form1_Load(object sender, EventArgs e)
{
this.TopLevel = true; //default anyway
Form.ActiveForm.TopMost = true;
this.TopMost = true;
}
But as you can see, a notepad window or any window can cover it.
Added
I have tried every suggestion made so far.
In response to Han's advice, "Of all the possible places to set TopMost property, the Load event is the worst. It should be set in the constructor, so the window gets created top-most right away. Or it should be set after it is visible, so after the Load event. Use the constructor. ". I tried putting those lines in the constructor.
public Form1()
{
InitializeComponent();
this.TopLevel = true; //default anyway
//Form.ActiveForm.TopMost = true; (commented to prevent a System.InvalidOperationException, presumably the form isn't yet active at this stage)
this.TopMost = true;
}
And the the other two suggestions, from others-
I tried setting the Form's TopMost field in the designer to True.
And running the EXE directly rather than just clicking play in visual studio.
Same issue.
And if you find that hard to believe, i've taken a 1min video here showing just that. https://screencast-o-matic.com/watch/cbXXrw2oTN
A potentially useful comment was mentioned..
Steve comments - "OK something definitively odd is happening here. I have tried to create a simple topmost form using linqpad and at the first run I get your same behavior. At the second run though everything works as expected."
A workaround, is this, following on from Han's point to put not put it in Load. Load is indeed too early. I've been finding that (at least on the system with the issue), The Constructor is also too early. I find that putting it in the Shown event, works.
One possible solution to this, is to run this patch, https://support.microsoft.com/en-us/help/2587473/topmost-windows-are-not-always-in-the-topmost-position-in-windows-7-or But be warned, if you want to uninstall it, I have some doubts whether it uninstalls correctly. And it's also not clear to me whether the patch is working or working sporadically. It likely works but it's hard for me to tell.
One commenter thought it's just my system, though that's not the case, as Steve ran into the same issue the first time he ran it. I find it may be most prone to happen after windows restarts, So, the program is running very fresh. But I find that putting that code in the Shown event, is fine and the form stays on top.
I tried instead of TopMost=true, using SetWindowPos, to set the window on top, I tried it fairly early like in the constructor, and late, like in the Shown event or on a button click, and I found it was fine in the Shown event or on a button click. So the issue was related to the TopMost=true line, or SetWindowPos line, firing too early, prior to the window it is setting appearing.
When calling SetWindowPos later one can use either this.Handle or GetForegroundWindow(), the former is easier as it's native. When calling it earlier one must use this.Handle. And using this.TopMost=true avoids all winAPI calls completely.
So in short, you could try the patch, though note that it might not uninstall right.. Or you can try the workaround of putting this.TopMost=true in the Shown event of the form.
I have an application that allows users to browse through data. I have menu items controlling navigation and a RichTextBox displaying the data. Very straightforward.
tl;dr version
It mostly works except for one strange problem. There are instances where the RichTextControl will replace the first character typed with a random unicode character. Feel free to download this sample app and see for yourself:
http://www.technitivity.com/stackoverflow/RichTextFocusTest.zip
Full Explanation
The issue happens when navigating between rows. It's best described with a few use cases:
Use Case 1
Navigate anywhere into the dataset.
Press back.
Press next.
Type any letter, say, "F".
Result: "F" appears in the RichTextBox as expected.
Use Case 2
Navigate anywhere into the dataset.
Press back twice.
Press next twice.
Type the letter "F".
Result: instead of "F", "ᅲ" appears in the RichTextBox.
Use Case 3
Navigate anywhere into the dataset.
Press next twice.
Press back twice.
Type the letter "F".
Result: instead of "F", "᧴" appears in the RichTextBox.
The navigation process entails nothing more than:
// either forward
i++;
// or backward
i--;
// then update
RichTextBox1.Text = MyData[i];
Procedurally speaking:
// This works
RichTextBox1.Text = MyData[3];
// This works
RichTextBox1.Text = MyData[3];
RichTextBox1.Text = MyData[2];
RichTextBox1.Text = MyData[3];
// This doesn't work
RichTextBox1.Text = MyData[3];
RichTextBox1.Text = MyData[2];
RichTextBox1.Text = MyData[1];
RichTextBox1.Text = MyData[2];
RichTextBox1.Text = MyData[3];
Granted, that's not what's actually happening, but it is what's effectively happening.
It's important to note that this doesn't happen if the RichTextBox loses focus between updates. It only happens if the RichTextBox retains focus while its Text attribute is updated in accordance with the above description.
I'm at a complete loss about what's causing this, how to fix it, or why I can't seem to find anyone else with this problem.
I've reproduced it on 64-bit Windows 7 and 32-bit Windows Vista. This is on .NET Framework 4 though I was also able to reproduce on a .NET Framework 2 project.
Here's hoping someone else has run across this (and solved it!)
Edit:
Here's a screenshot:
http://www.technitivity.com/stackoverflow/RichTextBox-Screenshot1.png
As mentioned in the comments, to reproduce this in the sample app, you have to use the keyboard menu shortcuts. If you click on the menu items (or the toolbar buttons), the RichTextBox loses focus and the problem goes away. But if you navigate through the items using Alt+Left or Alt+Right (back/next) and then type, you should see something like what's shown in the above screenshot.
I hesitate to call this an "answer", but I couldn't find a "Post a Hack" button and this hack does get me by for now. I'm not thrilled about it, but sometimes you just have to move on. Here it is.
Since the problem went away when the RichTextBox lost focus, I tried an experiment:
I created a visible, 0-pixel wide textbox, called Hacktastic.
I added a KeyPress event to the RichTextBox.
On KeyPress:
Hacktastic.Focus();
Hacktastic.Text = KeyChar.ToString();
MyRichTextBox.Focus();
This worked and (at least for now) I'm sticking with this as a solution. If anyone could still try out my sample project and reproduce and/or solve this, I would love further feedback:
http://www.technitivity.com/stackoverflow/RichTextFocusTest.zip
Steps to repro in the test project:
Using Alt+Right arrow, move through the dataset to, say, the fourth record.
Using Alt+Left arrow, move back through the dataset two places, to the second record.
Using Alt+Right arrow, move back to the fourth record.
Press any KeyChar.
Observe KeyChar is replaced with a "random", large-value unicode character.
I say "random" because a specific set of navigation (back/next) keystrokes will insert the exact same unicode character. However, depending on where you start in the set or how far back you go, you'll get a different character.
Also, note that only going back one record and forward one record does not cause the problem. You have to move at least two records for this to happen.