 |
|
|
 |
|
 |
I'm somewhat close to finding a similar to TAction behaviour by using ApplicationSettings and PropertyBindings. However I'm new to C# and the problem I have is after setting a property from within the designer (remember the goal is to write as less code as possible) C# adds this to the form's source page:
this.button1.Enabled = global::WindowsApplication1.Properties.Settings.Default.Test;
Now, accessing this would be with something like this:
MessageBox.Show(Properties.Settings.Default.Test.ToString());
The problem is that this is a read-only property. What am I missing? I'm sure there's a way... If not like this, with DataBinding perhapps.
Of course this would only be usefull for some state in controls, still don't have a clue on how to handle the Events.
|
|
|
|
 |
|
 |
Great work.
Caming from a Delphi experience, where ActionList is a powerful tools, i was trying to reproduce it on .NET too.
In your solution i see that the only controls that can act as an ActionClient are those derived from ButtonBase and ToolStripItem. The solution i was trying to reach is a bit different and i'd like to ask you, what do you think about it: i introduced an Interface (IactionClient) with some methods and properties, and every control that wants to act as an action client should implement such interface (pratically in IActionClient there are the method to update the Client Control when an action property change and a wrapper to associate the Execute event of the action with a choosen event of the client control). I know the the con's of this approach are that for every control i want to transform in an ActionClient i must implement this interface, but, from the other point of view, in this way, every component can became an ActionClient.
If you want i can send you my code (I don't post it here because is far from be complete).
|
|
|
|
 |
|
 |
M.Genuini wrote: I don't post it here because is far from be complete
Hi!
Interesting. Could you plan to publish your component?
----
Dmitry
|
|
|
|
 |
|
 |
There's been another ActionList on Code Project for the last three years:
http://www.codeproject.com/cs/miscctrl/actionlist.asp
Has anyone tried them both?
|
|
|
|
 |
|
 |
That other one is a more complete implementation, and it works on VS 2002, and includes icons and update events. However, there's some kind of bug in it that causes the VS 2003 form designer to remove Execute event handlers. I think the best solution might be to start with this one, and add some of the missing functionality to it.
|
|
|
|
 |
|
 |
Hi,
great Idea, but could you please provide a version for
Visual Studio 2003 with the Framework 1.1?
It would be great!!
Thanks a lot and a nice day
|
|
|
|
 |
|
 |
Delete the lines with ToolStripItem. And it should work.
|
|
|
|
 |
|
 |
Hey,
it seems that this is not all that i must do.
The Compiler doesnt understand the syntax
example:
public partial class ActionListProvider : Component, IExtenderProvider, ISupportInitialize
{
private Dictionary ActionDictionary = new Dictionary();
the "<" chars....
Sorry im not using .net 2.0 so i dont know what i must do to implement this to the
1.1 framework.
I hope you can help me one more time.
Thanks and a nice day.
cheers denis
|
|
|
|
 |
|
 |
I use generics. So you cannot so simple compile it under 1.1. You must use HashTable instead of Dictionary and cast the elements. I have only 2.0 Beta and no VS.NET 2003
Ladislav
|
|
|
|
 |
|
 |
Can't this be done by decalring an event handler and then assigning several events to be handled by it? At least the multiple event part that you mentioned.
e.g.:
// in InitializeComponents()
printButton.Clicked += new EventHandler(PrintClicked);
printMenuItem.Clicked += new EventHandler(PrintClicked);
//elsewhere
private void PrintClicked(object sender, System.EventArgs e)
{
Print(myData);
}
|
|
|
|
 |
|
 |
Of course you make it manualy. The benefit is that you can change your event handling for all your buttons in the action instead of on each button. The second benefit is that you can enable and disable the buttons with 1 line code.
|
|
|
|
 |
|
|
 |
|
 |
Actions and ActionLists are more than just a centralized event handler.
For example, in most conventional RAD, menu items and toolbar buttons have properties for a glyph (or listview imageindex), a checked/pushed state, enabled/disabled state, and so on.
Actions are a way to encapsulate a logical UI item's visual appearance, image/glyph; caption text; and other states like checked/unchecked, enabled/disabled etc., in a single place.
So, rather than associating glyphs, captions, enabled/disabled state, pushed state, and other things directly with toolbar buttons and menu items, we associate those things with actions, and then reference the action from a toolbar button or menu item.
Hence, if I set a given UI action to disabled, the associated toolbar button and pull down menu item are both disabled.
In other words, Actions eliminate a mountain of code. They can also be useful in runtime UI customization too. A user can drag an action out of a listbox, drop it onto a toolbar or a pulldown menu, and you just create the button or menu item, associate it with the action, and you're done.
|
|
|
|
 |