Develop Reference

How do I transition between forms C# Winforms?

This may seem like a rather obvious and extremely newcomer question (and it is), but I've merely been attempting to transition between multiple forms in C# Winforms and somehow managed to encounter numerous complications:
To begin, I used the obvious:
frm_hub hub = new frm_hub();
hub.Show();
However, each time this code run, a new instance of frm_hub was created and using hub.Close(); would not work because it was not closing the same new instance of frm_hub
Is a way to close the same instance of a form from a different form - say with a global variable? Or is there some way to integrate a Close(); so the entire program continues to function and new form displays?
As a possible solution to the above issue, I tried to store the same form as a variable:
frm_hub hub = new frm_hub();
private void OpenForm()
{
hub.Show()
}
However the runtime error: 'System.StackOverflowException: 'Exception of type 'System.StackOverflowException' was thrown.' was showing when I attempted to use this same tactic of storing the form as a variable in the two forms.
Why is this error occurring? And is there any way I can overcome it?
Finally, during some reading to counter this issue I discovered the use of controls and panels, and in this way, I could create an interface that opens different the different forms in a panel
However, my attempt of this required the use of anchors to get the form to display remotely true to the Designer appearance
If I do not require the form to be resizable, how can use panels to display a different form and at that in a way that displays the design elements how I have them positioned
Apologies again for my beginner understanding and use of terminology, feel free to seek clarification for crucial details I probably haven't included haha,
Thank you!

I used the following, not sure it's best practice. I used a button ShowFrmHubButton and disabled it when the window is already shown.
In my example the second form is modal, and you can't use the first window as long as the second is displayed.
ShowFrmHubButton.IsEnabled = false;
var frmHubWindow = new frm_hub ()
{
Owner = this
};
frmHubWindow.ShowDialog();
ShowFrmHubButton.IsEnabled = true;
Then, when you close\cancel the second form use this.Close();

HelpProvider ignores form's HelpTopic on some controls

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

Want to take data from one form to use them as variable in an other

I'm almost done doing a Connect4 game with VS2012 using WinForms. Everything is working well but I wanted to bring the options for the user on a dedicated Start Menu window. On that menu I have two comboBoxes I need to take the text from to use them as a value for two variables in my other form (the game window). I also have one New Game button that should call a method from my other form if that's possible (basically, I made an "Initialization()" method in my game form and I'd like it to be launched when I click the "New Game" button on the other form).
I only found tutorials that show how to do very basic things from one form to an other (such as labeling texts) but I I didn't find an answer to my specific problem.
I used this in my main form to instantiate the menu form
public FormMenu myMenu;
myMenu = new FormMenu();
What I want to do is that I could do something like this in the other form :
amountOfRows = Int32.Parse(myMenu.comboBoxRows.Text);
amountOfColumns = Int32.Parse(myMenu.comboBoxColumns.Text);
Any idea how I could do that?

I would love to see some example code so I can help see where your confusion lies. WinForms requires the other form to be instantiated.
OtherForm form = new OtherForm();
Once the form is instantiated you should be able to run code from it.
EDIT:
Based on your implementation I would suggest making public methods within FormMenu that return these int values.
public int ReturnRows()
{
return Int32.Parse(myMenu.comboBoxRows.Text);
}
public int ReturnColumns()
{
return Int32.Parse(myMenu.comboBoxColumns.Text);
}
Then from the other form in which myMenu is instantiated you can call myMenu.ReturnRows() and myMenu.ReturnColumns()

The easiest way would be to store a reference to your form in the menue as a variable. (you already named it myMenu)
Then you should create the property/properties you need in the form an add a setter for the values. (see example here)
Last you update the form fields with
myMenu.property = newvalue;
That`s all about it

Static reference to instance in IE Toolbar

I am having an interesting issue with a COM component written to function as a toolbar in IE. Basically if you open up several tabs at once in IE the individual instances of the COM objects get all twisted around. Bear with me here.
Say I open up five browser tabs all at once by right clicking several different links and opening them in new tabs. Now a function of my toolbar involves selecting text in the web page and then clicking a button to copy that text into the Toolbar. So let's do that in tab 3. We select text and click the button and nothing is there. However, if we select text in tab 2, then go back to tab 3 and click the button we get the text selected in tab 2. So...the toolbar in tab 3 getting stuff from tab 2. Not good.
I have traced this problem back to static references inside our COM object, the toolbar.
[ComVisible(true), Guid("2CC75392-1182-470D-BECC-EFA33E629AB8")]
[CLSCompliant(false)]
public sealed class Toolbar : ADXIEToolbar
{
public static Toolbar Instance;
public Toolbar()
{
Instance = this;
InitializeComponent();
}
...other code...
}
Note only one toolbar instance exists per each IE tab.
This reference doesn't get assigned properly, almost like it isn't thread safe (it isn't) but instead not domain safe or something. It will sometimes reference another instance down the line. Same with other static fields and even thread-safe singletons. I don't get it.
Also note that if I pass a reference to this toolbar (inside InitializeComponent) to a control I have the same issue.
this.publicationDateCb.Toolbar = this;
This reference will sometimes point to a different tab.
If I use a purely subscription based model with absolutely zero static references with the toolbar as the referee then things seem to work fine. This basically means I would have to re-design the program to where no classes interacted with each other directly - they fire events that the toolbar subscribes to, calling methods in other classes. Ouch.
So should I go with that model (which may be ideal but I am pretty far along here) or is there a simple fix I am missing here?
Other notes:
All IE tabs are running in seperate processes.
The BHO/Toolbar is running in the same process as the IE tab.
I am using Add-In-Express for Internet Explorer to handle the IE integration.
The project is written for .NET 3.5; the loader uses .NET 2.0

If you want to share your selected text within all your toolbars you can look at: http://www.add-in-express.com/creating-addins-blog/2009/06/19/internet-explorer-plugin-settings-synchronize/

Problem solved but static references are gone. I did a few things:
First off, I changed the target .NET version to 4.0. Apparently BHOs written in 4.0 work better - I can't find a link to substantiate this claim but I have read it somewhere.
More importantly I did away with static references within the assembly altogether. I got rid of the singletons and instead created a property for each former singleton class in my Toolbar class, which will always be unique. I then passed a reference to the Toolbar whenever a class needed to reference a former singleton.
So...constructors look like this now:
internal class RegistryData
{
public RegistryData(Toolbar toolbar)
{
ToolbarRef = toolbar;
}
...
}
And let's say RegistryData needs to call Messaging.
private void RegistryUpdated(int keyId)
{
ToolbarRef.Messaging.SendMessage(keyId);
}
Huge pain, right? Hours of work. But problem solved. I would not be shocked if this issue were related exclusively to Add-In-Express.

Using the HelpProvider class to show help, UI is always behind help window

I have a C# Winforms app that uses the HelpProvider class.
Whenever i press F1 to bring up help, the help window will always be on top of my application, I cannot bring my application UI to the foreground. I can still interact with my UI, but the help window will remain on top.
Is this by design of HelpProvider? Or am I missing something?

There is a solution to this issue, a bit dirty, but it works.
The thing is, the help window opened by HelpProvider is always on top of its parent window control, which is determined by Control instance in first parameter of Help.ShowHelp. Even if you specify null there, the main application form is still used as parent window.
To avoid this, one can create a dummy form, which will be used as a help parent form. This form will be never shown, but still, help window will be “on top” of it, effectively being NOT on top of all other application windows.
public static class AppHelp
{
private static Form mFrmDummyHost = new Form();
public static void ShowChm()
{
Help.ShowHelp(mFrmDummyHost, "my_help.chm");
}
}
Of course, all other Help.ShowHelp overloads can be called this way as well.
Hope this helps people like me, searching for answers to never-getting-old questions ;)

It is indeed by design, and its something that i did not realise. I have just recompiled my final year project and confirmed it. I have read up about it and basically the help file is set to TopMost=True every time the form is clicked. This means even if you code your form to be TopMost, as soon as you click the help file it will go back on top again.
I do believe if you use start process, it should get around the issue at the loss of some customisability the help provider gives.
private void textBox1_KeyDown(object sender,
System.Windows.Forms.KeyEventArgs e)
{
if(e.KeyCode ==Keys.F1)
{
System.Diagnostics.Process.Start(#"C:\WINDOWS\Help\mspaint.chm");
}
}
Hope it helps