Develop Reference

One method successfully toggles a control's "Enabled" property - a similar method fails. Why?

In my code behind I have two method to enable or disable a group of controls depending upon the value of a field on a form. One of these methods works as expected, and the other doesn't ... quite. The one that works depends upon the value of a Checkbox, while the other depends upon the value of a drop-down list (I believe that this difference is irrelevant - I mention it only for completeness). I've simplified these methods for readability, but the only significant difference from the production system is that they set a number of controls, not just one.
private void SetControlsFromDropDown(int statusID)
{
// This method doesn't work
bool enable = (statusID == (int)ReqStatus.CompletedOK)
this.myTextBox.Enabled = enable;
}
private void SetControlsFromCheckBox(bool enable)
{
// This method works
cboMyDropDown.Enabled = enable;
}
Where the first method fails is that it sets the controls correctly when the form is loaded. However, when the drop-down list changes, the method is called and the value of the bool variable "enable" is correctly set, and the code runs through as expected (and a watch on the Enabled property of the controls that are being set shows that they are toggled as expected) - BUT BUT BUT the controls remain firmly unchanged in the interface. So, if they were initially set to Enabled = false they remain disabled even though the method might have set them to Enabled = true.
What is causing me conniptions is that if I put setting of this.myTextoxBox into the second method, it toggles correctly.
I get the impression I haven't explained myself very clearly. In essence, two more-or-less identical methods, called from similar events, operating in arguably indistinguishable ways, behave differently in real-time. One will toggle the Enabled property of a group of controls ad lib., while the other will toggle it once, never to be toggled again.
Any thoughts gratefully received.
Edward

The problem was caused by a failure of the brain. I was getting an incorrect value from the drop-down list. Apologies for any time wasted.

I'm not really sure about this, but try to remove the 'this'
Just put the following:
myTextBox.Enabled = enable;

2 or more Controls only 1 is considered Active

I have 2 controls (MyCtrl) next to each other called ctrlLeft and ctrlRight.
Whenever one receives interaction it is considered active (by default the left one). I override OnDraw and customize the look of the active one a bit.
Currently I have a property Active and an event that I subscribe to from all MyCtrl in there I store a reference to the active one like this:
if (sender is MyCtrl)
{
ctrlActive = (sender as MyCtrl);
ctrlLeft.Active = !(ctrlRight.Active = (ctrlActive == ctrlRight));
}
Either way I need to have ctrlActive as I use it for other things but what I am wondering is if this is the best way make them aware of each other?
Another option I thought of was to store references to every possible MyCtrl and then loop through em all and activate / deactivate the one that match sender just in case I in the future add a ctrlMiddle.
Are my thoughts wrong, is there better options to do this. For example, how does radiobuttons accomplish their similar functionality?
Edit: Thanks for all suggestions.
In my particular case I don't want/need a container as even if I have 3 MyCtrl only one can still be active and I don't want them to be "linked" 2 and 2 so I went with a public static MyCtrl { get; set; } that each control can check itself against and I can update it where I need to, which works in my case and rids me of the need to loop through a collection when using multiple MyCtrl.

Your methods are sound. If you need multiple controls with only one being active consider a container (visual or otherwise) where the children supply an "activate" event TO the container and the children also subscribe to a "control activated" event FROM the container....if the child is not the control supplied by the containers "control activated" event..then paint it as not active otherwise paint as active.

You have to manage the activation by yourself, so I think that your method is good.

I nearly had the same idea as Rusty. But i would make it a little more general.
Why not building a container control that contains two panels (like SplitContainer). The container control has a property Active of type enum ActivePanel { First, Second } and it can be switched from outside by a setter or automatically through a subscription of the container to the Focus event (or something similar).
With such an approach you also don't need a ctrlMiddle cause you can nest your container multiple times.
I think there are still some problems to solve by this idea, but it should give you a good direction.

How to set NotifyIcon behavior to AlwaysShow in C#?

Is it possible to modify NotifyIcon behavior to AlwaysShow in C#? A code snippet would be greatly appreciated:) Thanks in advance...
Cheers
---edited
One of our clients said quote "it seems necessary to customise icons to always show". What he meant was that he has to do it manually by r-clicking on task bar then click on Properties -> Task Bar -> Customize Notifications and then you can set behavior to Always Show / Always Hide / Hide when inactive for each taskbar icon on the list.
Can you do that programically in C#?
I want to ensure that my NotifyIcon is ALWAYS visible. I'm already setting icon.Visible = true but it looks like it doesn't work for him hence the complaint.
Is there any easy way of setting the behavior by altering [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify] IconsStream registry value?

NotifyIcon icon = ...;
icon.Visible = true;
Edit for updated information: There shouldn't be, and if for some reason it exists, don't use it. That's the user's preference, not yours.

I'm sure it's possible with enough Registry hacking, but not at all recommended. They added the collapsing-notification-area behavior in XP because so many applications were shoving themselves in that space. Much like Start Menu pinning behavior in XP/Vista/7, the lack of a public API means you're supposed to let the user decide that sort of thing.

How bad is the following snippet?

My question is simple: how bad is the following snippet of code? How would you do it?
CancelEventHandler _windowClosing;
private CancelEventHandler WindowClosing
{
set
{
clearEventHandlerList();
this.Closing += value;
_windowClosing = value;
/*
* if calling the method with null parameters,
* it will set up itself as the primary control on the Window
*/
_windowClosing(null,null);
}
get
{
return _windowClosing;
}
}
private readonly CancelEventHandler[] CONTROLS = null;
private int current = 0;
public InitializerForm()
{
InitializeComponent();
/*
* these are the handlers for the different controls,
* in the order of appereance to the user
*/
STATES = new CancelEventHandler[] { handler1, handler2, etc. };
WindowClosing = CONTROLS[0];
}
private void clearEventHandlerList()
{
foreach (CancelEventHandler c in CONTROLS)
{
this.Closing -= c;
}
}
private void handler1(object obj, CancelEventArgs e)
{
if (obj == null)
{
//hide every other control, but this one, also set up if necessary
}
else
{
//do something
WindowClosing = CONTROLS[++current]; // set the next control to show
e.Cancel = true;
}
}
The point would be that the code wouldn't close a form, but instead show another component on it, and the set the way to handle that (this is mobile platform, so clicking OK button on the top generates a closing event). This is because showing several forms (4 or 5) one after another to the user makes the app blink, and also very annoying, while replacing just components is much smoother. This model works, but seems very nasty, and I would like a cleaner way to handle this.
Update:
I updated the code sample so that variable names are somewhat speaky. Still, I'm convinced this is awful, (a) but not sure how much, and more importantly, (b) how to do it better.
Update 2:
So, it seems that the code is still a bit mysterious.
Now here's what the problem is:
I show the user a form, which instructs him what to do in several languages. He proceeds by clicking OK on the window. Next, I ask for his language, and then a few questions (where his/her GPS is, etc.) like this. After he could answer the questions (this shouldn't take more than a few seconds each), I show him a splash screen (I load stuff in a separate thread meanwhile), which has a picture. Showing these forms one after another makes the whole application start slow, and filled with UI lags.
Here's what I do to work around the lags: I put the content of the windows into panels, and put those panels one on another, and hide every one of them but the one that should be visible to the user. (current variable) Each of the windows does different things, so I need to change handler of the window closing event in addition. In this code the part which enables the panel is in the same function (handler1, handler2, etc.) with the part which handles the window closing event. If the arguments are null, it does the former, if it isn't (that means it was triggered by the user) it does the latter.
I need an extensible solution to this so that I can insert and remove dialogs anytime I want (the order and the pointers to the functions are stored in the CONTROLS field, and this seems to be very convenient, if you actually understand it. Although it is never easy to change the entire content of a form, there ought to be a simpler way to do this, as well a nicer one, that is what I'm looking for.
I hope this time I could explain how the model works.

I think it might be theoretically possible to make that code more delightfully diverting, perilously puckish, jovially jeopardous, cheerily chancy and unwarily whimsical but it would require some serious thought.

somehow your code makes me want to cry, i´m sorry. i read it twice and all i know about it is that it "doesStuff" with "STATES".
if you really want some help on this one you will have to work on it yourself first...

Use, XML! It's human-readable!
More seriously-
It seems like you're trying to create some sort of configuration wizard, so I'd start by researching that. Regarding your particular solution, I generally advocate very strongly against the "layered panel" approach. I do so because I maintain apps written by people who found this approach, or the related "hidden tabs on a tab control" approach, to be a good idea. It's not, and maintainers will curse your name for years to come.
That being said, what alternatives are there? Well, one alternative is what you've already dismissed because of its "flicker". I'd say that, in general, the flicker isn't that big of a deal for a quick and dirty application. It might be a good idea to make sure that your new window is called up before closing the old one, for example. (I'm assuming this is possible, I haven't developed on a mobile device.)
Another possibility might be a less-evil version of your layered panels. Instead of throwing a half-dozen panels into one form, create a separate user control for each wizard page and then add/remove the user controls to a containing form. This can avoid your flicker and will prove to be much easier to maintain because each page is in a different control. This might also ease any subsequent "Back" button functionality and make your data structures more naturally defined because those user controls will be associated with a specific logical bit of data. It's still not ideal, but it's probably good enough for a one-off solution.
A third technique, if you foresee extensive wizard modification as the product matures, might be to generalize the creation of your user controls by defining them in a more logical/declarative manner (e.g. via XML). If you dynamically generate sensible controls based on XML, then modifying the panels might be as easy as diving into your XML and doing something like:
<Questions>
<Question type="Text"> <!-- generate a textbox for the answer field -->
Favorite Color:
</Question>
<Question type="Number" range="0-255"> <!-- Maybe this is a spinner -->
The answer to life, the universe, and everything:
</Question>
</Questions>
That's just off the top of my head, and completely overkill for any one-off application, but it's a possibility.

Now, let me caveat this by saying this might work, but it may not be the answer to your real problem - that of a slow and unresponsive UI when you have a lot of forms. The real answer may be to just go ahead and do all separate forms, but have each form load its child forms in a background thread while the user is staring at the first form.
But assuming you're still set on this, I'd start off by making a separate class just to handle the Panel stacking/hierarchy. Call it PanelManager. You would instantiate the PanelManager and associate it with the main form, then add Panels to it (perhaps keyed to a String) and set the order. In the main form, have the closing handler call PanelManager.CloseCurrentPanel() and if there are no more Panels to show then it's time to close the main form.
Time for pseudo-code! Here's a quick idea for the class, i'll leave it to you to implement it:
public class PanelManager {
// constructor
public PanelManager (Form ownerForm);
// short-cut properties
public Panel this[int idx]
{ get; set; }
public int Index
{ get; set; }
// main functionality
public int AddPanel (Panel p);
public void SetPanelOrder (Panel p, int idx);
public void RemovePanel (Panel p);
public void RemovePanelAt (int idx);
// shows the first Panel
public void Show ();
// shows Panel[idx]
public void Show (int idx);
// adds the panel to the top of the stack and displays it
// returns the index of the panel
public int AddPanelAndShow (Panel p);
// hides the current panel, displays the one underneath it
// returns false if there are no more panels
public bool HideCurrentPanel ();
}
in the constructor for the main form, instantiate it by new PanelManager (this), then in the closing event handler, call panelManager.HideCurrentPanel () and then figure out whether or not you need to close it after that.

How can I create a Delphi TSpeedButton or SpeedButton in C# 2.0?

How can I create a Delphi TSpeedButton or SpeedButton in C# 2.0?

Using a Button and setting the TabStop property to false only works when tapping through the form...
If you need (as I did) a button that does not get selected when clicking on it, there is only one way I have found to do it.
The way I did it, was to subclass the Button class and in the constructor calling the SetStyles and thereby setting Selectable to false, like so:
public class ButtonNoFocus : Button
{
public ButtonNoFocus()
: base()
{
base.SetStyle(ControlStyles.Selectable, false);
}
}
This worked out for me, and is perfect if you e.g. have a control-panel with buttons that perform actions to a selected object...

I'm wondering if you want to create a control like a TSpeedButton, or you just need same kind of end result ...
Programming one from scratch is certainly possible, but I'd only tackle that as a learning exercise.
Assuming you want to achieve a similar end result ...
Delphi's TSpeedButton had a differences from the standard TButton that developers found useful - it was flat, didn't take focus, and it consumed fewer resources than a regular button (because it didn't have an underlying Windows Handle).
Which of these are important to you?
If you just want a flat button that doesn't accept focus, use a regular Button with FlatStyle=Flat (or PopUp) and TabStop=false. You can configure a glyph by setting either the Image property, or a combination of ImageList and ImageIndex/ImageKey.
An alternative to this would be to look for an existing button component that comes close to your needs - one place to look might be the Krypton Toolkit (free to use, see http://www.componentfactory.com/toolkit_buttoncontrols.php).
If you're wanting to reduce the number of resources consumed by your application, it's likely you'll get a better return looking elsewhere.
Back in the days of Windows 3.1 (Delphi 1) and Windows 95 (Delphi 2), the number of available handles was strictly limited, with a maximum number available system wide. Today, with Windows XP and Vista, the number of available handles is far far higher, and the number is per process, not system wide. Unless you're creating thousands upon thousands of buttons, you're very unlikely to come anywhere close to running out.

Does this help? Looks like you would have to handle the OnPaint event, and not take focus...

The regular .net 2.0 button supports part of what a TSpeedbutton Does:
The Glyph: Image
Flat : FlatStyle
It does not handle:
Down
Group
These two are related, you could inherit from the button, and ownerdraw it, adding Down and Group features.
Codeproject has an example of ownerdraw buttons.