Results 1 to 4 of 4

Thread: A few developer questions about the API

  1. #1
    Join Date
    Mar 2003
    Location
    London, UK
    Posts
    294

    Default A few developer questions about the API

    I was hoping some of the more experienced Girder plugin developers could help me with some questions about the API.

    1. Documentation says that Config and Action UI’s have to be “non-blocking” as opposed to Event UI which can block. Some of the source I’ve looked at spawns these UI elements off on another thread. Is this strictly necessary or will it suffice to make these non-modal dialog boxes on the main thread?

    2. gir_command_gui does not pass the command to be edited. gir_command_changed provides this so I can see how you track changing selections once the UI is up, but how do you know which command is selected at the point were the UI is first displayed? Do you simply have to cache info from gir_command_changed all the time, even when the UI is not active?

    3. When Girder is being shut down, at exactly what point is GIRINFO_QUERYUNLOAD being called? I ask because in my XP addin I look for WM_QUERYENDSESSION and WM_ENDSESSION messages. The former are seen, but not the latter. I tried responding false to the first GIRINFO_QUERYUNLOAD and true to the next expecting this to delay shutdown long enough for me to see WM_ENDSESSION, but no dice. Does Girder start unloading plugins in response to the WM_QUERYENDSESSION message?

    Thanks in anticipation,

    John

  2. #2
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    1) Using a non-modal dialog on the thread you are called with is risky. If Ron changes the way the threads work (priority, which threads are responsible for what, etc.) the behavior of your plugin will change. If you are using an "environment" that helps you build GUIs easier (MFC, Delphi, etc.), the clash of the Girder environment with yours can cause problems. The safe way is to spawn a UI thread.

    2) Cache the pointer from gir_command_changed() all the time. This pointer can be NULL!

    3) I don't know. My guess is your plugin is unloaded before the WM_ENDSESSION message occurs.
    Mark F

  3. #3
    Join Date
    Mar 2003
    Location
    London, UK
    Posts
    294

    Default

    Thanks Mark,

    Looks like I need to brush up on threading in my chosen C++ library (ATL)!

    - John

  4. #4
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,553

    Default

    3. Girder doesn't do much with the WM_QUERYENDSESSION. When the WM_ENDSESSION comes in Girder spawns a separate thread that closes everything down. The WM_ENDSESSION thread waits for this to finish. So your plugin will have been closed before getting the WM_ENDSESSION message.
    Ron
    No support through PM

Posting Permissions

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