A better way to write / read dozens of textboxes? - Page 3
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 3 of 3 FirstFirst 123
Results 31 to 42 of 42

Thread: A better way to write / read dozens of textboxes?

  1. #31
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by TheGreatCthulhu View Post
    With the option turned on, once you create a UserControl-derived class and build it, it will automatically be added by the IDE to the toolbox, at the very top, under it's own category.
    Is that automatic toolbox addition confined to the solution from which I add the component then? For instance, most of my apps certainly wouldn't need a 7-seg digit class, even less a stopwatch component class. Otherwise I might prefer to explicitly disable that feature if it's enabled by default, to prevent the toolbox from getting polluted with custom control classes actually unrelated to most other projects.

    (Actually, I put the stopwatch component into a DLL of which the stopwatch application is merely a client. That way I can use the component in other apps in any desired and supported way I like. While the stopwatch can be embedded as a control in any form, I currently don't make use of that feature in any of my apps. However, the stopwatch component also is capable of creating its own rudimentary form, and I make use of that feature by late-loading the component in a few of my apps where timing may be of interest in debugging. However, there's only one of my apps where even the release version does support that, and there the feature is activated by specifying the path to the stopwatch DLL in an undocumented app.config entry or simply copying the stopwatch DLL to the app directory. Rather expert stuff, so...)

    Looks like I'm ruminating too much. Time to go to bed...
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  2. #32
    Join Date
    Jan 2010
    Posts
    1,102

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by Eri523 View Post
    Is that automatic toolbox addition confined to the solution from which I add the component then? For instance, most of my apps certainly wouldn't need a 7-seg digit class, even less a stopwatch component class. Otherwise I might prefer to explicitly disable that feature if it's enabled by default, to prevent the toolbox from getting polluted with custom control classes actually unrelated to most other projects.
    Yes, the additional toolbox items should only appear if the user control project is part of the solution (and it will show only when a form designer is active). So there will be no toolbox pollution .

    For referenced assemblies, you'll have to use the "Choose items..." option (or you can simply open a file explorer and drag the dll file onto the toolbox).
    Last edited by TheGreatCthulhu; November 9th, 2012 at 01:47 PM.

  3. #33
    Join Date
    Jun 2011
    Posts
    25

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by TheGreatCthulhu View Post
    Please let me know if this works out.
    Aaargh! I tried again and it worked... I think I must have copied one of the other references like IContainerControl or maybe just a typo but when I replaced the declaration with:


    public ref class Fader : public System::Windows::Forms::UserControl


    it just worked... WOW When it didn't work first time because I wasn't expecting it to be something so simple I just gave up. Most profuse apologies to all.


    So in this context no need to create user controls/dll's just build the composite and use the class straight off. (see example project zip below)

    Anyway what I was working on was the user interface as I wasn't happy with the methods like passing "this" from Form1 or using "owner" property. (this is really getting a bit off topic...) There has been some previous discussion on this subject but I haven't seen this method used before. It seems (to me) it may be more "correct" because it naturally avoids the circular inclusion problem and the neccessity of declaring methods as public. I think this is correct but prepared to be proven wrong. Hope someone wiser can spare the time to review and appraise this example. NB: my vs. of Winzip doesn't work on this Win7 PC and the free zipper I found is a bit strange as it won't let me zip from the top level folder so hope this can be reconstructed correctly (in "EncapsTest" folder originally.)

    ETest.zip

    Many thanks for brilliant and unstinting help (as always)
    RogerD

    PS: still working through the earlier posts so may be a while before I can catch up...
    Last edited by RogerD; November 9th, 2012 at 02:59 PM.

  4. #34
    Join Date
    Jan 2010
    Posts
    1,102

    Re: A better way to write / read dozens of textboxes?

    I see what you did. Basically, the Fader class is relying mostly on delegates, which you use to model events, to communicate with client code.

    That is not wrong, public events are a part of the public interface, but there are a few caveats - I'll get back to that later.
    You also expose some data that's potentially interesting to client code through the Anno and EqValue properties.

    In relation to your comment from the last post: having public methods is not wrong per se, it's just that public methods should be there for a reason - you don't want to expose some method used for some kind of internal calculation, or internal management, but you might have some public methods that would make sense for client code. For example, if your Fader control was animatable, and you could animate the position of the trackBar over time, you could declare a public Update(double timeElapsed) method as a legitimate part of the public interface.

    Next, as buttons, checkboxes, and numericUpDowns are internal member variables of the Fader class, these should definitively be private! If some aspect of them needs to be exposed as well, it should be done through the public interface of Fader (you don't even have to expose the internal controls themselves, you translate requests back and forth in the same way as you did with events - in the Form1 class, you didn't hook up to the events of the actual controls, but to those of the Fader, and then Fader did the rest).

    This is important, because if these are not made private, client code (like Form1 class) can directly access any of those variables and, for example, set them to nullptr or replace them completely with different controls of the same type, or worse, with controls derived from that type (and this can be dangerous, if the intentions of the developer are malicious)!

    Now, about the events.
    You were right to assume that events and delegates are pretty close concepts, if not the same. But, the way you implemented them now, they will not appear in the Properties window as events, and you'll not be able to use the Properties to assign event handlers in the same way you'd use it for other controls.

    There's a special syntax for declaring events, and it looks like this:
    Code:
    delegate void ClickEventHandler( int, double );
    delegate void DblClickEventHandler( String^ );
    
    ref class SomeClass {
    public:
       event ClickEventHandler^ OnClick; 
       event DblClickEventHandler^ OnDblClick; 
    };
    Under the hood, the event keyword implicitly creates what's known as event property; the concept is similar to the normal properties, except that the backing field is a variable of the specified delegate type.
    You can also explicitly declare an event using the event property syntax, and explicitly control how exactly the event get's hooked up with it's handler(s), which is sometimes useful. See this for more detail.

    Anyway, if events are declared like this, they will be treated by the IDE as... well, events.
    Another thing is the signature of the event handler. While there's no requirement for the handlers to have the signature (Object^ sender, EventArgsType^ e), that is what most people would expect, although it's a bit of a drag to create all those EventArgs derived classes. Sometimes it's not required though, as the owning object might use public properties and/or methods of the Fader object to retrieve the data it wants, considering that the name of the event provides semantic context ("what is it that happened").

    The .NET library provides some help in the form of the EventHandler<T> generic delegate (note: this is not a C++ template), which enables you to at least avoid delegate declarations, and declare your events like this:


    event EventHandler<EventArgsType^>^ OnClick;


    where EventArgsType^ is a EventArgs-derived class, at least by convention - it actually can be any type.

    For example, the handler method for


    event EventHandler<int>^ EqValueChanged;


    would be


    void MethodNamePlaceholder(Object^ sender, int faderID);

    EDIT:
    BTW, .Net generics aren't too hard to learn, and although they are not templates, they are similar in some ways - an important difference is that, while templates are resolved at compile time, generics are substituted with the actual types at runtime. There are some other significant differences, too. Here's a quick tutorial from CodeGuru.
    Last edited by TheGreatCthulhu; November 9th, 2012 at 04:19 PM.

  5. #35
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by TheGreatCthulhu View Post
    [...] where EventArgsType^ is a EventArgs-derived class, at least by convention - it actually can be any type.
    Interesting; that seems to have changed from .NET 4 to 4.5 (the version your link points to). The .NET 4 version of the same MSDN page shows the signature with a constraint requiring the type argument to be an EventArgs derivate. Or is simply one of the two documentation pages wrong?
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  6. #36
    Join Date
    Jan 2010
    Posts
    1,102

    Re: A better way to write / read dozens of textboxes?

    You are right! Actually, I think I originally just wanted to write "EventArgs-derived class.", and to end the sentence there, but then I went to the documentation and noticed that there are no type constraints, so I added the second part (it felt a bit strange, but I didn't think much of it...).

    I'm guessing that it's more likely that the 4.5 docs are wrong in that respect?

    Anyway, I better correct that statement, so:

    The handler method for

    event EventHandler<EventArgsType^>^ EqValueChanged;


    would be

    void MethodNamePlaceholder(Object^ sender, EventArgsType^ e);


    where EventArgsType is a class derived form EventArgs.
    Last edited by TheGreatCthulhu; November 9th, 2012 at 05:27 PM.

  7. #37
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: A better way to write / read dozens of textboxes?

    Quick reality check - under .NET 4 the first one compiles, the second one doesn't (error C3214):

    Code:
    public ref class TestClass
    {
    public:
      event EventHandler<EventArgs ^> ^TestEvent;
    };
    
    public ref class TestClass2
    {
    public:
      event EventHandler<int> ^TestEvent;
    };
    Don't have access to .NET 4.5 to check with that.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  8. #38
    Join Date
    Jun 2011
    Posts
    25

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by TheGreatCthulhu View Post
    Please let me know if this works out.
    I tried this out but VC++ crashed at step 6 I tried the Auto load setting you mentioned later but that had no effect so I tried Choose items... on a new project/empty form - same result. 2 hours later after a windows update session (that took a couple of updater updates to get update working!) I started VC and it came up with last project which was the one I uploaded that I built with Component Class. There at the top of the toolbox was the component all ready and waiting to drag-drop... ! It looks as if Component class DOES work after all I will test tomorrow on a raw project.
    RogerD
    P.S. yes it certainly seems to work:- Project>Add new item>Component class. Somewhere in this thread, I'm sure, there's an explanation for why the class derives from System::ComponentModel::Component instead of System::Windows::Forms::UserControl...
    EDIT:
    So to recap for anyone else reading this - in the above example (and in the context of the original question) there's no need to create DLL and the extra project. Just add a Component class - Project>Add new item>Component class, inherit from System::Windows::Forms::UserControl (instead ofSystem::Windows::Forms::Form) , build it and if AutoToolboxPopulate is enabled the component appears on the toolbox. If you want to use it outside the project create the dll as above. (Or copy the class file(s). NB you can drag the dll onto the toolbox if that's any easier.)
    Last edited by RogerD; November 12th, 2012 at 05:41 AM.

  9. #39
    Join Date
    Jun 2011
    Posts
    25

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by TheGreatCthulhu View Post
    You are right! Actually, I think I originally just wanted to write "EventArgs-...
    I'm a bit lost now! This is purely about the generic form which is restricted to the standard event signature (i.e. EventArgsType), right? If you want to use the non-standard parameters list you use the delegate?

    I note that the original example
    Code:
    delegate void ClickEventHandler( int, double );
    results in "empty" parameters (i.e. param0 for the int...) in the default handlers while
    Code:
          delegate void ReadyEventHandler(int FaderID); 
    //results in 
    private: System::Void fader1_OnReady(System::Int32 FaderID) {}
    which is a bit more useful.

  10. #40
    Join Date
    Jan 2010
    Posts
    1,102

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by RogerD View Post
    I'm a bit lost now! This is purely about the generic form which is restricted to the standard event signature (i.e. EventArgsType), right? If you want to use the non-standard parameters list you use the delegate?
    Yeah, we were talking about the constraints specific to the EventHandler<T> generic delegate - but you can use any user defined delegate type.

    Quote Originally Posted by RogerD View Post
    I note that the original example
    Code:
    delegate void ClickEventHandler( int, double );
    results in "empty" parameters (i.e. param0 for the int...) in the default handlers while
    Code:
          delegate void ReadyEventHandler(int FaderID); 
    //results in 
    private: System::Void fader1_OnReady(System::Int32 FaderID) {}
    which is a bit more useful.
    Are you talking about auto-generated code? In the example, I was just trying to explain the concept, but if you want to rely on code generation, then you should definitely provide parameter names. As you probably know, in C++ parameter names can be left out in function declarations, and even if they are there, the parameter names in function definition don't have to match - in order for the compiler to decide which function to call, the compiler has to know the signature, but variable names are not needed; they are simply there so that a human can refer to them inside the function, and to make the code more readable. Same thing for delegate declarations.

  11. #41
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,594

    Re: A better way to write / read dozens of textboxes?

    Well, I admit this is slightly OT, but the thread already is so versatile...

    Quote Originally Posted by TheGreatCthulhu View Post
    [...] As you probably know, in C++ parameter names can be left out in function declarations, and even if they are there, the parameter names in function definition don't have to match - in order for the compiler to decide which function to call, the compiler has to know the signature, but variable names are not needed; they are simply there so that a human can refer to them inside the function, and to make the code more readable. [...]
    Yes, the compiler doesn't require them, and quite some time ago, due to plain laziness, I tended to omit parameter names in function declarations (except in a few cases where I used them to improve human readability). But not much later I found out that the debugger uses the prototype names of parameters in its valiable display (locals and auto window, probably watch window as well, but I use that quite rarely). So if you omit them, the debugger will display the parameters nameless, and at the latest that will get somewhat confusing/annoying as soon as you have more than one parameter of the same type in a single function's parameter list. So since found out about that, I'm giving names to all the parameters in my prototypes and also recommend doing that to others.
    Last edited by Eri523; November 24th, 2012 at 03:56 PM.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  12. #42
    Join Date
    Jan 2010
    Posts
    1,102

    Re: A better way to write / read dozens of textboxes?

    Quote Originally Posted by Eri523 View Post
    So since found out about that, I'm giving names to all the parameters in my prototypes and also recommend doing that to others.
    Oh, yes - I agree; especially for class member function declarations in header files, since these are a form of documentation for the class. Good parameter names should tell you what the function does, and what are the semantics of each parameter.

    But for the purposes of code snippets in forum posts, when the context is clear from the discussion, i think it doesn't hurt to avoid some repetition, so I sometimes omit them.

Page 3 of 3 FirstFirst 123

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center