[ann] WIN32GUI - v1.5.1 released

Discussion in 'C++' started by John Torjo, Oct 13, 2004.

  1. John Torjo

    John Torjo Guest

    Hi all,

    Version 1.5.1 of WIN32GUI has been released.
    Get it from: http://www.torjo.com/win32gui/


    Win32GUI is a FREE generic library for GUI programming on the Windows
    platform, developed in parallel to "Win32 GUI Generics" column in
    C/C++ Users Journal.

    It is portable, and currently can be compiled with gcc3.3+, vc7.1,
    como 4.3.4+ and vc8 (experimental)

    Features:
    * (v1.5) tooltips. So easy to use, and they work for *menus* too!
    * (v1.5) bitmap buttons (they can be set at dialog design time)
    Works for push-like check-boxes and radio button as well
    You can easily set "hot tracking" for a certain bitmap button
    And, they work on MessageBox too!!!
    * (v1.5) added hyper_links at dialog design time
    * (v1.5) lite HTML class (also, you can set at design time)
    * (v1.5) tab dialogs - and you can also set them at dialog design time
    (much better than MFC property pages!)
    * (v1.5) message reflection
    * dialog design time splitters
    * easy to create a dialog on a dialog
    * thread-safe
    * (v1.4+) save_dlg - true binding of your data to UI controls!!!
    * very easy to subclass controls/dialogs
    * very easy to deal with windows generically (finding out all
    children/windows
    of a given type, finding out windows that match a certain criteria)
    * GUI RAII (as a window gets created on screen, its C++ object gets
    created; as it gets destroyed from screen, the C++ object gets
    destroyed as well)
    * revolutionary simple event handling (no message maps)
    * thin yet powerful wrappers over all standard controls
    (button,edit,...toolbar,rebar,etc.)
    * easy menu command manipulation (menu commands that behave like
    checkboxes/radio buttons)
    (you'll find examples in sub-directory examples/menus)
    * tray window

    And much more!

    And last but not least, 40+ examples and counting!

    Best,
    John

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 13, 2004
    #1
    1. Advertising

  2. On 13 Oct 2004 18:16:56 -0400, (John Torjo) wrote:

    >Version 1.5.1 of WIN32GUI has been released.
    >Get it from: http://www.torjo.com/win32gui/
    >
    >
    >Win32GUI is a FREE generic library for GUI programming on the Windows
    >platform, developed in parallel to "Win32 GUI Generics" column in
    >C/C++ Users Journal.


    Just out of curiosity ...
    - Why do you write a library for the legacy Windows-API?
    - Why don't you use "modern" approaches like XUL, XAML, ...?

    Best regards,
    Roland Pibinger

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Roland Pibinger, Oct 14, 2004
    #2
    1. Advertising

  3. John Torjo

    John Torjo Guest

    (Roland Pibinger) wrote in message news:<>...
    > On 13 Oct 2004 18:16:56 -0400, (John Torjo) wrote:
    >
    > >Version 1.5.1 of WIN32GUI has been released.
    > >Get it from: http://www.torjo.com/win32gui/
    > >
    > >
    > >Win32GUI is a FREE generic library for GUI programming on the Windows
    > >platform, developed in parallel to "Win32 GUI Generics" column in
    > >C/C++ Users Journal.

    >
    > Just out of curiosity ...
    > - Why do you write a library for the legacy Windows-API?


    I wouldn't call it legacy. It's quite a nice piece of work, with the
    right wrapper on top of it ;)

    > - Why don't you use "modern" approaches like XUL, XAML, ...?


    Indeed "modern" ;)
    As I understand, XUL only allows for scripting, and its event model is
    quite simplistic.

    (note: I'll touch the event handling in the docs quite these days - so
    check it out ;)
    Also, stay tuned for the Dec '04 issue of CUJ - you'll be pleasently
    surprised.)

    As for XAML, just a new M$ "technology".
    There are a *very* few things I like about it - painting mostly. Other
    than that, just another high-level specification (a little better than
    ..rc files) - but quite unflexible, if you ask me.
    And from what I've read, I really don't like the way it handles
    events. I failed to see how can you actually listen to all events that
    get triggered by an application.

    But most of all, I hate "Avalon", since it deprecates Standard C++.


    I will certainly deal with Longhorn, when it comes out ;)

    Best,
    John


    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 15, 2004
    #3
  4. [snips]

    On Wed, 13 Oct 2004 18:16:56 -0400, John Torjo wrote:

    > Win32GUI is a FREE generic library for GUI programming on the Windows
    > platform...


    > It is portable...


    So which is it? Is it for Windows only, or is it portable? Good; where
    can I get it for, say, X under Linux? Or the Amiga?



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Kelsey Bjarnason, Oct 18, 2004
    #4
  5. On 16 Oct 2004 21:39:57 -0400, ppliu wrote:

    >Thanks,John,It's an excellent job!
    >IMO,Win32 GUI is the most elegant GUI lib so far.


    Do you mean the C++ code and dezign is elegant or the user interface
    stuff is elegant. How does it compare with WTL, Microsoft's Win32 C++
    template GUI library?

    Graeme

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Graeme Prentice, Oct 18, 2004
    #5
  6. Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Wed, 13 Oct 2004 18:16:56 -0400, John Torjo wrote:
    >
    >> Win32GUI is a FREE generic library for GUI programming on the Windows
    >> platform...

    >
    >> It is portable...

    >
    > So which is it? Is it for Windows only, or is it portable? Good;
    > where can I get it for, say, X under Linux? Or the Amiga?


    Portability can also mean from compiler to compiler or from one OS version to
    another.

    Regards,
    Paul Mensonides



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Paul Mensonides, Oct 18, 2004
    #6
  7. John Torjo wrote:

    > Hi all,
    >
    > Version 1.5.1 of WIN32GUI has been released.
    > Get it from: http://www.torjo.com/win32gui/



    I do not want to stop your effort, however doesn't .NET already do the
    same things?


    Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
    Win32.

    Win32 will not be developed any more and will remain for compatibility
    purposes, the same way Win16 is today.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Ioannis Vranos, Oct 19, 2004
    #7
  8. John Torjo

    John Torjo Guest

    Graeme Prentice <> wrote in message
    news:<>...
    > On 16 Oct 2004 21:39:57 -0400, ppliu wrote:
    >
    > >Thanks,John,It's an excellent job!
    > >IMO,Win32 GUI is the most elegant GUI lib so far.

    >
    > Do you mean the C++ code and dezign is elegant or the user interface
    > stuff is elegant. How does it compare with WTL, Microsoft's Win32 C++


    I would say both - but that definitely makes me biased ;)

    > template GUI library?
    >


    So I gather you haven't read CUJ ;)

    I guess you can compare it yourself. As a matter of fact, I'm working
    on the docs right now
    (which you can get from http://sf.net/projects/win32gui/).
    I'm posting docs versions daily - and welcome all feedback.

    Also, you can check out the examples to get you started - there's 41
    of them so far.

    Best,
    John


    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 19, 2004
    #8
  9. Ioannis Vranos <> wrote in message news:<1098142257.716016@athnrd02>...

    > I do not want to stop your effort, however doesn't .NET already do the
    > same things?
    >
    >
    > Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
    > Win32.
    >
    > Win32 will not be developed any more and will remain for compatibility
    > purposes, the same way Win16 is today.


    Win32 will be around for a long time. Not everyone will move to
    Longhorn immediately. There are some things you can't do easily in
    ..NET today.
     
    20thCenturyBoy, Oct 20, 2004
    #9
  10. 20thCenturyBoy wrote:
    > Ioannis Vranos <> wrote in message news:<1098142257.716016@athnrd02>...
    >
    >
    >>I do not want to stop your effort, however doesn't .NET already do the
    >>same things?
    >>
    >>
    >>Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
    >>Win32.
    >>
    >>Win32 will not be developed any more and will remain for compatibility
    >>purposes, the same way Win16 is today.

    >
    >
    > Win32 will be around for a long time. Not everyone will move to
    > Longhorn immediately. There are some things you can't do easily in
    > .NET today.



    Win32 will be around for a long time, for backwards compatibility. All
    newer facilities will be provided in WinFX/.NET only.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Oct 20, 2004
    #10
  11. John Torjo

    John Torjo Guest

    Ioannis Vranos <> wrote in message
    news:<1098142257.716016@athnrd02>...
    > John Torjo wrote:
    >
    > > Hi all,
    > >
    > > Version 1.5.1 of WIN32GUI has been released.
    > > Get it from: http://www.torjo.com/win32gui/

    >
    >
    > I do not want to stop your effort, however doesn't .NET already do the
    > same things?
    >


    And by the way, could you please point me to how .net + threading +
    GUI interact?
    Since it seems to me that they interact kind of badly...

    On my small C# project I made, it seems that if I do something like

    static void other_thread1() {
    g_form.txt.Text = "other thread -1";
    }


    and, make sure I catch the text_changed event:

    private void changed_txt(object sender, System.EventArgs e)
    {
    int i = 0;
    }

    I catch this in the context of the other thread, as opposed to the
    main thread (which is what I would expect). Thus, I need to make my
    whole class thread-safe, just because I want to manipulate one of its
    controls from another thread.

    This strikes me as very bad, compared to Win32 programming, where all
    messages are sent on the context of the thread that created the
    control, not on the context of the caller.

    Best,
    John

    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 20, 2004
    #11
  12. John Torjo

    John Torjo Guest

    Ioannis Vranos <> wrote in message
    news:<1098142257.716016@athnrd02>...
    > John Torjo wrote:
    >
    > > Hi all,
    > >
    > > Version 1.5.1 of WIN32GUI has been released.
    > > Get it from: http://www.torjo.com/win32gui/

    >
    >
    > I do not want to stop your effort, however doesn't .NET already do the
    > same things?


    I would say that compared to .net, the overhead is much smaller. You
    don't need .net to be installed in your machine (what about making
    install kits?). Not to say that I find .net very inflexible. And it
    seems I'm not the only one...

    As the other thread (CLI draft) showed, the C++/CLI does have a while
    until it will catch on, etc. win32gui works *now*. Not to say that I
    intend to provide advanced subclassing, which as far as I know - is
    quite impossible under the .net.

    >
    >
    > Also keep in mind that the Longhorn API will be WinFX (.NET), replacing
    > Win32.


    I've read about it.

    >
    > Win32 will not be developed any more and will remain for compatibility
    > purposes, the same way Win16 is today.


    That remains to be seen. From what I've read, I see *no* advantages of
    using Avalon, other the GDI.

    If Avalon proves to catch on, there won't be anything to stop me from
    porting win32gui to it ;) In fact I might consider allowing the user
    of the library to choose between using or not using Avalon (of course,
    this is just a thought, for now)

    Best,
    John


    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 20, 2004
    #12
  13. John Torjo wrote:

    > And by the way, could you please point me to how .net + threading +
    > GUI interact?
    > Since it seems to me that they interact kind of badly...
    >
    > On my small C# project I made, it seems that if I do something like
    >
    > static void other_thread1() {
    > g_form.txt.Text = "other thread -1";
    > }
    >
    >
    > and, make sure I catch the text_changed event:
    >
    > private void changed_txt(object sender, System.EventArgs e)
    > {
    > int i = 0;
    > }
    >
    > I catch this in the context of the other thread, as opposed to the
    > main thread (which is what I would expect). Thus, I need to make my
    > whole class thread-safe, just because I want to manipulate one of its
    > controls from another thread.



    I do not understand C#, so can you make it C++?


    In C++ with "managed extensions" the threads go like this:


    __gc class SomeClass
    {
    // ...

    public:
    void SomeMethod();
    };

    // ...

    SomeClass *obj= new SomeClass;



    Thread *thread1= new Thread( (new ThreadStart(obj,
    &SomeClass::SomeMethod) );


    thread1->Start();



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Ioannis Vranos, Oct 21, 2004
    #13
  14. John Torjo

    Glen Low Guest

    > And by the way, could you please point me to how .net + threading +
    > GUI interact?
    > Since it seems to me that they interact kind of badly...
    >
    > On my small C# project I made, it seems that if I do something like
    >
    > static void other_thread1() {
    > g_form.txt.Text = "other thread -1";
    > }
    >
    >
    > and, make sure I catch the text_changed event:
    >
    > private void changed_txt(object sender, System.EventArgs e)
    > {
    > int i = 0;
    > }
    >
    > I catch this in the context of the other thread, as opposed to the
    > main thread (which is what I would expect). Thus, I need to make my
    > whole class thread-safe, just because I want to manipulate one of its
    > controls from another thread.


    In your other thread code, you need to ask the form to InvokeAsync a
    delegate you provide. If the delegate is fairly arm's length, and can
    be fired and then forgotten, you don't need any other thread
    synchronization mechanisms. Also, the text changed event executes in
    the context of the form's thread not your other thread.

    In any case, the point is moot. Win32 uses the same mechanism; each
    thread has its own message queue and only in the context of the main
    UI thread is it safe to do UI stuff. If another thread needs to change
    the text of a control or something more complicated, you do a
    PostMessage to the UI thread queue, which is equivalent to
    InvokeAsync. No doubt if you've properly wrapped the message passing
    in your library, then your library has cleaner syntax than .NET --
    however, when you need to get information back from a control e.g. the
    text of a control, when you're in a different thread you would either
    have to code a wait or get the control to PostMessage you back, so
    there's that thread safety issue again.

    Mac OS X is similar. You have a main GUI thread; if another thread
    needs to muck around with the GUI, you have to post a message to it. I
    don't know if any GUI system freely allows any thread to perform GUI
    operations.

    Cheers,
    Glen Low, Pixelglow Software
    www.pixelglow.com

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Glen Low, Oct 22, 2004
    #14
  15. John Torjo

    John Torjo Guest

    >
    > That remains to be seen. From what I've read, I see *no* advantages of
    > using Avalon, other the GDI.


    That was a little strong...

    There are a lot of good things about Avalon, I just find a quite too
    "high level" (that is, it makes me wish for a lower level API). It's
    still too early to tell...
    Besides, I'd really like it if I could do CLI/C++ coding for Avalon -
    which at this time I don't think is possible.

    Best,
    John

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 22, 2004
    #15
  16. John Torjo

    Seanairt Guest

    On Fri, 15 Oct 2004 18:19:50 -0400, John Torjo wrote:

    > But most of all, I hate "Avalon", since it deprecates Standard C++.


    How can it possibly "deprecate" the standard? Further, wouldn't that mean
    their current work with VC 7.x is time/money wasted? They've put all this
    work into making the current series of the IDE their most
    standard-compliant yet. Indeed, this is the chief reason I bought 7.1. I
    rarely code against .Net, having a large # of projects coded against MFC
    and/or ATL.
    IOW, I realize how they may encourage (and push and prod) you into coding
    against the .Net/Avalon sctuff, but wouldn't the standard still be there
    underneath (and indeed, supporting) it all?


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Seanairt, Oct 22, 2004
    #16
  17. John Torjo wrote:
    >
    > That was a little strong...
    >
    > There are a lot of good things about Avalon, I just find a quite too
    > "high level" (that is, it makes me wish for a lower level API). It's
    > still too early to tell...
    > Besides, I'd really like it if I could do CLI/C++ coding for Avalon -
    > which at this time I don't think is possible.



    "Avalon" (a subset of WinFX) will be equally accessible from all .NET
    languages, especially C++/CLI, so I do not know what you mean exactly
    with the above.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Ioannis Vranos, Oct 23, 2004
    #17
  18. John Torjo

    John Torjo Guest

    Ioannis Vranos <> wrote in message news:<1098330500.577454@athnrd02>...
    > John Torjo wrote:
    >
    > > And by the way, could you please point me to how .net + threading +
    > > GUI interact?
    > > Since it seems to me that they interact kind of badly...
    > >
    > > On my small C# project I made, it seems that if I do something like
    > >
    > > static void other_thread1() {
    > > g_form.txt.Text = "other thread -1";
    > > }
    > >
    > >
    > > and, make sure I catch the text_changed event:
    > >
    > > private void changed_txt(object sender, System.EventArgs e)
    > > {
    > > int i = 0;
    > > }
    > >
    > > I catch this in the context of the other thread, as opposed to the
    > > main thread (which is what I would expect). Thus, I need to make my
    > > whole class thread-safe, just because I want to manipulate one of its
    > > controls from another thread.

    >
    >
    > I do not understand C#, so can you make it C++?
    >
    >
    > In C++ with "managed extensions" the threads go like this:
    > [...]
    >


    That was not the point. The point is: the context in which you catch
    notifications (that is, in the thread that created the window, or in
    the thread they occur?)

    In other words:
    I'm in another thread, and do this:

    g_form.txt.Text = "other thread -1";

    I would expect to catch the text_changed notification in the main
    thread (the thread that created g_form).

    Best,
    John


    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 23, 2004
    #18
  19. John Torjo

    John Torjo Guest

    (Glen Low) wrote in message news:<>...
    > > And by the way, could you please point me to how .net + threading +
    > > GUI interact?
    > > Since it seems to me that they interact kind of badly...
    > >
    > > On my small C# project I made, it seems that if I do something like
    > >
    > > static void other_thread1() {
    > > g_form.txt.Text = "other thread -1";
    > > }
    > >
    > >
    > > and, make sure I catch the text_changed event:
    > >
    > > private void changed_txt(object sender, System.EventArgs e)
    > > {
    > > int i = 0;
    > > }
    > >
    > > I catch this in the context of the other thread, as opposed to the
    > > main thread (which is what I would expect). Thus, I need to make my
    > > whole class thread-safe, just because I want to manipulate one of its
    > > controls from another thread.

    >
    > In your other thread code, you need to ask the form to InvokeAsync a


    how can I invoke async:

    g_form.txt.Text = "other thread -2";

    I'm not sure I follow...

    > delegate you provide. If the delegate is fairly arm's length, and can
    > be fired and then forgotten, you don't need any other thread
    > synchronization mechanisms. Also, the text changed event executes in
    > the context of the form's thread not your other thread.


    that's what I hoped for. But the 'Call Stack' showed me something
    else...


    WindowsApplication1.Form1.changed_txt(sender =
    {System.Windows.Forms.TextBox}, e = {System.EventArgs}) Line 123 C#
    [<Non-user Code>]
    WindowsApplication1.Form1.other_thread1() Line 30 C#


    >
    > In any case, the point is moot. Win32 uses the same mechanism; each


    If that were true... Which it seems not.

    If I'm correct, Win32 is much better (see below)

    > thread has its own message queue and only in the context of the main
    > UI thread is it safe to do UI stuff. If another thread needs to change
    > the text of a control or something more complicated, you do a
    > PostMessage to the UI thread queue, which is equivalent to


    In fact, you can still do SendMessage (check the SDK) between threads.
    The OS will change the context to the thread that created the window,
    wait for it to process this, and then return.

    In fact, I've made a small sample to show how easy it works using
    win32gui:
    http://www.torjo.com/code/multiple_threads3.zip

    > InvokeAsync. No doubt if you've properly wrapped the message passing
    > in your library, then your library has cleaner syntax than .NET --
    > however, when you need to get information back from a control e.g. the
    > text of a control, when you're in a different thread you would either
    > have to code a wait or get the control to PostMessage you back, so
    > there's that thread safety issue again.


    Nope. You can, again, use SendMessage (check out the code)
    For instance:
    w->text("some text");
    or
    std::string = w->text();
    will work correctly, no matter on which thread w was created on.

    >
    > Mac OS X is similar. You have a main GUI thread; if another thread
    > needs to muck around with the GUI, you have to post a message to it. I
    > don't know if any GUI system freely allows any thread to perform GUI
    > operations.


    And yet, Win32 seems to just fit the bill....


    Best,
    John


    John Torjo, Contributing editor, C/C++ Users Journal
    -- "Win32 GUI Generics" -- generics & GUI do mix, after all
    -- http://www.torjo.com/win32gui/
    -- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons, tab dialogs, hyper links, lite html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Torjo, Oct 23, 2004
    #19
  20. John Torjo

    Glen Low Guest

    > how can I invoke async:
    >
    > g_form.txt.Text = "other thread -2";
    >
    > I'm not sure I follow...


    Define a method and delegate

    void ChangeText (TextBox box, String newText) { box.Text = newText; }
    public delegate void ChangeTextDelegate (TextBox box, String newText);

    then in your other thread, do

    g_form.Invoke (new ChangeTextDelegate (ChangeText), new object []
    {box, newText});

    (Sorry about misleading you about the InvokeAsync, that was a holdover
    in my gray cells from the old WFC days, it should be just Invoke...
    BTW, all this works equivalently in Managed C++, so it's still on
    topic...)

    Admittedly the syntax is clunky, especially for simple methods. But if
    your method needs to do a lot of work the syntactic overhead is not
    much, since you would have to do the equivalent with PostMessage and
    packing and unpacking the arguments yourself.

    > that's what I hoped for. But the 'Call Stack' showed me something
    > else...
    >
    >
    > WindowsApplication1.Form1.changed_txt(sender =
    > {System.Windows.Forms.TextBox}, e = {System.EventArgs}) Line 123 C#
    > [<Non-user Code>]
    > WindowsApplication1.Form1.other_thread1() Line 30 C#


    Ooo.. that would mean that you made the text change directly in your
    non-GUI thread, a definite no-no.

    > In fact, you can still do SendMessage (check the SDK) between threads.
    > The OS will change the context to the thread that created the window,
    > wait for it to process this, and then return.


    Yes you can, but this hides the latency behind the SendMessage. When
    your other thread calls SendMessage, it blocks as the GUI does its
    work, and also waits for the function return. In a typical threaded
    design, you want the other thread to continue to do work while the GUI
    updates e.g. if the other thread is reading a giant file from the
    network or busy rendering something. Excessive use of SendMessage then
    causes both threads to be serialized, and you might as well just use
    one thread instead of two.

    Therefore, a lot of developers who use Win32 strictly seperate GUI and
    non-GUI functionality in their threads. Then if the non-GUI thread
    needs to get the GUI to do something, they define a custom message on
    the GUI thread that does all of what they want, then they PostMessage
    the custom message to it to get it to work. The thread boundaries are
    much clearer and little serialization occurs, the GUI remains
    responsive and the non-GUI thread works at almost full speed.

    Now this pattern (I wonder if there is a GOF term for it) is almost
    exactly the same as the .NET delegate + control invoke async. Except
    that the .NET version does the argument packing and custom message
    number allocation for you.

    Cheers,
    Glen Low, Pixelglow Software
    www.pixelglow.com

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Glen Low, Oct 24, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    449
    matthias_k
    Jan 26, 2005
  2. =?ISO-8859-1?Q?Thomas_N=FCcker?=

    Embedded Python and Tkinter / win32gui

    =?ISO-8859-1?Q?Thomas_N=FCcker?=, Jun 24, 2003, in forum: Python
    Replies:
    2
    Views:
    1,282
    =?ISO-8859-1?Q?Thomas_N=FCcker?=
    Jun 25, 2003
  3. Martin v. =?iso-8859-15?q?L=F6wis?=

    Re: Compiling Python with Tkinter and win32gui

    Martin v. =?iso-8859-15?q?L=F6wis?=, Jun 27, 2003, in forum: Python
    Replies:
    0
    Views:
    861
    Martin v. =?iso-8859-15?q?L=F6wis?=
    Jun 27, 2003
  4. Jay O'Connor

    STrange error importing win32gui

    Jay O'Connor, Nov 12, 2003, in forum: Python
    Replies:
    4
    Views:
    411
    Mark Hammond
    Nov 13, 2003
  5. Corwan
    Replies:
    1
    Views:
    513
    Mark Hammond
    Feb 1, 2004
Loading...

Share This Page