I'm refactoring a body of code, looking through it all, line by line.
I came across an event handler:
private void mnuUpdate_Click(object sender, EventArgs e)
...and, not recognizing which menu item called this (the menu item names do not always match their labels, or even come close), was curious.
The main menu on the form has no such menu item among its children.
I r-clicked the event handler, selected "Find Usages*" and was led here:
this.mnuUpdate.Text = "Update";
this.mnuUpdate.Click += new System.EventHandler(this.mnuUpdate_Click);
(This is an antedeluvial app that predates .NET's partial class goodness, so this is in the same file)
On the form in the designer, when I select "mnuUpdate" from the properties page combobox, the mainMenu on the form disappears altogether.
How can I track down this fugitive menu item? There is no popupMenu or contextMenu on the form, just the mainMenu control...???
The only other usage is:
if (ResetConnectionFetchForm)
mnuUpdate_Click(sender, e);
Is it possible that this is simply a phantom menu item that should be converted into a "regular old" method?
UPDATE
As the most intelligent George used to say, "Curiouser and Curiouser." Now I find this:
public void btnCancel_Click(object sender, EventArgs e)
...and though it is called from seven places in the code, there is no btnCancel on the form...It is a "fake" button click event. Oh my Lanta!!!
So, I replaced it with a parameterless private method with the exact same code (it didn't use either sender or event args).
If the cat who wrote this cockamamie glob of fruitcake-battered spaghetti was deliberately trying to drive the next cat (me) crazy, it's working pretty well, and would make a good Poe-style story or Hitchcock-style flick.
...I see...Dead Code!!!
Okay, mystery solved. mnuUpdate is dynamically added (conditionally) to mnuSetup (which is a top level menu item with the Text property "Fetch") like so:
if (!mnuSetup.MenuItems.Contains(mnuUpdate))
{
mnuSetup.MenuItems.Add(mnuUpdate);
UpdateMenuItemSelectable = true;
}
I reckon selecting mnuUpdate from the combobox in the form's Properties page is because there is no visual representation to show at that point.
Selecting "mnuSetup" highlights the "Fetch" menu item, but selecting "mnuUpdate" causes it all to scurry away faster than cockroaches from the light.
So the bizarre thing about it now is: why is the menu item not dynamically created as necessary, instead of being explicitly created and then dynamically added; seems like a strange way for a cat to skin a cat.
I'd suggest you turn it into "regular old menu" so someone else doesn't waste time figuring it out.
Me - I would have thought it obsolete code because it doesn't have a Handles clause.
You can use .Visible and .Enabled to control what the user sees.
Related
I'm working in Visual Studio 2010 and I'm dealing with C#; I've made a statusStrip that I intend to use as my tool-tip viewer, its .text attribute changing depending on the control the mouse has entered. I've got two textBoxes and I'm trying to make it such that entering the control fires a function called tooltipEnter, and leaving it fires a function called tooltipLeave. Here's my code for those two functions:
private void tooltipEnter(object sender, EventArgs e)
{
toolStripStatusLabel1.Text = this.AccessibleDescription;
}
private void tooltipLeave(object sender, EventArgs e)
{
toolStripStatusLabel1.Text = "Look here for tool-tips regarding the form!";
}
The problem with this is that, first, I'm not sure AccessibleDescription is the right attribute to saddle the description to, and I'm not sure of the most elegant way to do the toolStripStatusLabel1.Text assignment in the first place. Second, this in the program's frame of reference refers to the form on which these controls lay, not the controls themselves; How do I refer uniformly to "the control that just got entered" in a way that allows me to have just the one function for all entries, without having to make different ones for each control?
The problem with this is that, first, I'm not sure
AccessibleDescription is the right attribute to saddle the description
to, and I'm not sure of the most elegant way to do the
toolStripStatusLabel1.Text assignment in the first place.
AccessibleDescription is just some string instance referenced in your form, from this code. The text assignment is done in the only way possible. I'm not sure what your question is regarding this.
Second, this in the program's frame of reference refers to the form on
which these controls lay, not the controls themselves; How do I refer
uniformly to "the control that just got entered" in a way that allows
me to have just the one function for all entries, without having to
make different ones for each control?
sender is always the object from which the event was raised in the EventHandler delegate: msdn.microsoft.com/en-us/library/system.eventhandler.aspx
I am sure that the answer to this has been posted before. Forgive me as I think I am just not thinking of the right search string.
What I have is a context menu strip assigned to my tray icon for my dialer. The idea is for the user to set various numbers and select the user defined numbers from the menu and initiate the dial.
So the menu pops up with Presets, Setup, & Exit. I want the Presets menu to open a new tree listing the user defined number. I also want this to populate from an xml file every time the application is loaded.
My problem is that I have no idea how to dynamically populate a sub menu item and give it a function.
So how would I at start up add user defined numbers to preset -> (userNumber1, usernumber2, userNumber3) and then call the dial() function when clicked?
So I found how to add to the list... I now feel silly for asking that. For anyone else who wants to know that one, The list item is given a name. Im my case the name attribute is " presetsToolStripMenuItem"
So to add an item to it call the name
presetsToolStripMenuItem.DropDownItems.Add(string text)
No to move on. I am stuck now trying to figure out how to assign an event to that newly added function. I did find
presetsToolStripMenuItem.DropDownItems.Add(string text, image, eventargs)
I am struggling with this one. Maybe I need to stop and come back to it later. Perhaps if someone could provide me with an example of using this line to call a function(); I would be most appreciative.
For anyone that is interested I figured out the solution to adding a context menu item at run time with the ability to call a function.
As stated before, to add a sub menu item to a a parent category, use the parent.name. So in my case the preset menu item name was "presetsToolStripMenuItem"
To add function I used the 3 argument method.
ToolStripMenuItem.DropdownItems.Add("string name", image, eventargs);
so my code looks like this:
presetsToolStripMenuItem.DropDownItems.Add("added2", null, disp);
void disp(object sender, EventArgs e)
{
MessageBox.Show("It works!");
}
I have an AutoCompleteBox binded to an ObservableCollection ItemsSource which I filter on my own by querying entities from a domainservice.
I used the scenario of populating from a webservice call from the blog of Jeff Wilcox, by setting the PopulatingEventArgs.Cancel to True, and when my collection is ready, I call PopulateComplete() on the ACB.
My goal is to reopen the dropdown on mouseover (or click) but without reloading again all the data from the web. I found a question on stackoverflow where the answer was to set IsDropDownOpen to True. But in this case, the ACB population starts again, and another call goes to the webservice.
Of course, when the user starts typing, the filtering should be done again.
(for ex. you type "ric" and the box suggests "rice" and "ricin", you select rice, but you change your mind and want to select another one from the same collection, lets say "ricin". In this case you already have the suggestions containing "ric" in memory, no need to load them again..)
I found an alternative way in which instead of setting IsDropDownOpen, I just simply call the PopulateComplete() method. This does exactly the same thing that I want, but with a little fail: after my ACB loses focus, the dropdown is not opened again on mouseover liek it should. Even when I click back into the acb textbox.
So is there a fix for this, or does someone know why the PopulateComplete() only reopens the dropdown when the ACB has focus for the first time? Or this was only my luck that calling this method reopened the dropdown and the IsDropDownOpen property should be used instead (afaik this would be only possible with some flags indicating that its a fake populating event triggered by my mouseover and after PopulatingEventArgs.Cancel i should call immediately PopulateComplete. but i dont get it, if this may work (haven't tried yet), why not when calling simply the PopulateComplete)?
Well, I tried the IsDropDownOpen with a testing bit, and almost worked:
private void FoodBox_MouseEnter(object sender, MouseEventArgs e)
{
//FoodBox.PopulateComplete(); not working after acb loses focus...
testbit = true;
FoodBox.IsDropDownOpen = true;
}
Here's the overloaded Populating method (no need for setting ItemsSource explicit because its bound to an ObservableCollection):
public void FoodBox_Populating(object sender, PopulatingEventArgs e)
{
e.Cancel = true;
if (!testbit)
{
VM.LoadFoodSuggestions(FoodBox.SearchText);
}
else
{
testbit = false;
FoodBox.PopulateComplete();
}
}
This works good so far, execpt that the search does not start because when (for the first time) you mouseover and select the acb, it sets the testbit to true.
So I added another event handler that takes care of setting the testbit to false every time the user inputs text on the keyboard, ensuring that the suggestions are regenerated/reloaded after SearchText is modified by the user, but not when you select an item from the dropdown:
private void FoodBox_TextChanged(object sender, RoutedEventArgs e)
{
testbit = false;
}
I still don't know why calling PopulateComplete() isn't enough without setting the IsDropDownOpen to Ture, and setting that to true, also delays the dropdown opening approximately with the time specified in the MinimumPopulateDelay, but at least it gives me the functionality I wanted. (Maybe digging into the source of acb would answer this mistery)
Maybe this functionality implemented in the basic acb would be helpful in a future release of the control.
In my windows application i have a context menu with a grid the problem is that I want to disable the ToolStripMenuItem in context menu according to the user previlages.How can i do that. i have done like this but it is not working
private void contextMenuStrip_Machine_Opening(object sender, CancelEventArgs e)
{
toolStripAuthorize.Enabled = INFOpermission.accessAuthorize;
}
but it is not working
You need to set toolStripAuthorize.Enabled to either true or false.
I have no idea what INFOpermission.accessAuthorize is because you didn't show the code that defines that (enum?), but if it's anything other than false, this isn't going to work out like you expect.
I can guarantee that setting the Enabled property of the ToolStripMenuItem that you want to disable to false in the Opening event handler will work. If it's not working for you, you're doing something else wrong, and you need to give us some more information to go on.
If you're stuck, see the sample code here: How to: Handle the ContextMenuStrip Opening Event
EDIT: Armed with new information provided in the comments, I've now isolated the source of the problem. You've assigned the ContextMenuStrip to the RowTemplate of a DataGridView control, and are therefore not able to modify items contained in that context menu in its Opening event handler method.
It turns out that this is a known bug that someone decided was "by design". You can see the original bug report here on Microsoft Connect. The explanation given is that whenever a new row is created based on the RowTemplate (which is how the RowTemplate works), the ContextMenuStrip that you've assigned gets cloned as well. That means the same context menu instance is not used for each row, and whatever properties that you try to set on the original menu items have no effect.
Fortunately, it also gives us a workaround. Like all events, the Opening event passes the actual instance of the ContextMenuStrip that is about to be opened as its sender parameter. This is the context menu whose items you need to modify in order for your alterations to be visible.
So what's the code? It looks like this:
private void contextMenuStrip_Opening(object sender, CancelEventArgs e)
{
ContextMenuStrip cmnu = (ContextMenuStrip)sender;
cmnu.Items[1].Enabled = false;
}
Notice, though, that you'll have to reference the individual menu item that you want to modify by its index. This is just the zero-based position of the item in the menu that you want to modify. You can't use the toolStripAuthorize object like you were trying to do before because a new instance of it has been cloned for each new context menu instance.
I'm attempting to use the ScintillaNET control in an application I am working on. I drag and drop the control into my form and run form. The control appears on the form. This is good. In addition, if I set any of the properties in the control's properties editor (ConfigurationManager.Language, for example), I am able to type in that language and see syntax highlighting occur.
Where I run into problems is when I attempt to change properties programmatically. For example, I attempt to load text from a file into the form (I'm doing this in the form's Load). The text doesn't display. I also can't seem to show the line numbers or do any other number of tasks (including programmatically change the Language).
Any idea what I may be doing wrong? Even something as simple as the code below doesn't seem to work:
private void scintilla1_Load(object sender, EventArgs e)
{
scintilla1.ConfigurationManager.Language = "xml";
}
Simply add scintilla1.ConfigurationManager.Configure();
private void scintilla1_Load(object sender, EventArgs e)
{
scintilla1.ConfigurationManager.Language = "xml";
scintilla1.ConfigurationManager.Configure();
}
After spending some time playing around with the different events, it appears that I cannot affect the Scintilla control until after it is already visible. Hence, the "Load" event does not let me make any programmatic changes to the control until I've set it visible.
It's a little strange, and seems sort of pointless to me to have the Load event at all, but I just wanted to let everybody know what is happening in case someone else ran into the same problem.