fake Modal Menu with getMessagePort()

"dev42" wrote:
In trying to roll my own Modal pop-up menu, I quickly ( it's all relative! )
learned that I can't have a Modal anything! My app needs to keep doing
stuff even when menus and such are on screen awaiting user input.

So, in using getMessagePort() to hijack my main event loop, it crossed my
mind that I could send other "doEvent()/Update()" functions as parameters
into my Fake-Modal Menu of Awesomeness.

Q: As much as the possibility of this working is intriguing, how often is
such a construct put into action? Is this a standard way of doing such
a thing? If not, why have a getMessagePort() at all?

Follow-up Q: Are easing animations typically modal as well? Who here has
implemented non-modal transition animations?

Thanks in advance.

peace & 42

Are you using the 2D api for this?

"Rek" wrote:
Are you using the 2D api for this?

Yes.

just pass control to a message loop in your modal dialog. Use getmessage instead of wait or waitmessage

"NewManLiving" wrote:
just pass control to a message loop in your modal dialog. Use getmessage instead of wait or waitmessage

could you expound on this a bit? What exactly do you mean by "pass control"? :oops: :?:

When you create your dialog you first draw it and then go into another message loop. But you do not use wait. Instead you use getmessage which returns immediately if there's no button pressed. it just returns invalid. So if you have to keep processing something you can continue until you notice some valid input. Of course what you are doing should not block the message queue either. If You have to block the queue then you don't even need a loop. What is it that you are trying to do?

"NewManLiving" wrote:
What is it that you are trying to do?

Code better? 😉 That really isn't a joke! I've apparently coded myself into a corner. I've been working on a game loop "framework" that I could use in the future and not just on the app I'm currently working on. One "feature" of this framework was that I allowed more than one object to process button events. Not only that, but some objects, depending on which button was pressed, could pass which button was pressed on to the next object in the list... or not.

To facilitate all of this, I started accumulating a bunch of boolean flags: .isVisible, .hasFocus, .isModal

Now I'm not saying I was completely wrong ( why would any programmer *ever* say that?! ), but I'm starting to see that I really was over-complicating things.

"NewManLiving" wrote:
another message loop

That's just it. I only had one loop. This is new territory for me. I'm currently working through the 7 Stages of Learning to Program Better ( aka Programming Grief ). I initially posted when at the first stage, Shock & Denial. I won't go into the other stages as I don't want to cause anybody undue stress revisiting their past programming learning journeys. 😉

"NewManLiving" wrote:
What is it that you are trying to do?

Topically? errr to learn if implementing more than one event loop is the way to go.

"dev42" wrote:

"NewManLiving" wrote:
What is it that you are trying to do?

Code better? 😉 That really isn't a joke! I've apparently coded myself into a corner. I've been working on a game loop "framework" that I could use in the future and not just on the app I'm currently working on. One "feature" of this framework was that I allowed more than one object to process button events. Not only that, but some objects, depending on which button was pressed, could pass which button was pressed on to the next object in the list... or not.

To facilitate all of this, I started accumulating a bunch of boolean flags: .isVisible, .hasFocus, .isModal

Now I'm not saying I was completely wrong ( why would any programmer *ever* say that?! ), but I'm starting to see that I really was over-complicating things.

"NewManLiving" wrote:
another message loop

That's just it. I only had one loop. This is new territory for me. I'm currently working through the 7 Stages of Learning to Program Better ( aka Programming Grief ). I initially posted when at the first stage, Shock & Denial. I won't go into the other stages as I don't want to cause anybody undue stress revisiting their past programming learning journeys. 😉

"NewManLiving" wrote:
What is it that you are trying to do?

Topically? errr to learn if implementing more than one event loop is the way to go.

We only use 1 run-loop in our app. The key is to arrange components in a hierarchy and allow them to register with their parents as event receivers. Whenever an event is pulled out of the message port in the main loop, send it to the root component. Each component then either handles the event, or forwards it to it's children, who can also handle, or forward it. Here's some pseudo code:

**Disclaimer** This was all typed directly into the forum... It might not compile/run, but should demonstrate the concept

   ' -----------------------------------------------
   ' Entry: Main
   function main() as Void
      runloop = runloopCreate()
   
     ' Create a button
     button = buttonCreate()
     button.setText("Click Me!") ' setText not included in example
    
     ' Add button
     runloop.getRoot().addChild(button)

     ' Execute
     runloop.run()
   end function

   ' -----------------------------------------------
   ' Class: Component

   function componentCreate() as Object
      return {
         handleEvent               : _component_handleEvent
         handleOrForwardEvent: _component_handleOrForwardEvent

         _children                  : []
         addChild                   : function(component as Object) as Object: m._children.push(component): end function
      }
   end function

   function _component_handleOrForwardEvent(event as Object) as Boolean
      handled = m.handleEvent(event)

      ' We did not handle the event, maybe our children will?
      if not handled
         for i = 0 to m._children.count() - 1
            handled = m._children[i].handleOrForwardEvent(event)
            if handled then exit for
         end for
      end if

      return handled
   end function

   function _component_handleEvent(event as Object) as Boolean
      return false ' No handling of events at this level
   end function

   ' -----------------------------------------------
   ' Class: Button

   function buttonCreate() as Object
      this = componentCreate()

      ' Override function handleEvent
      this.handleEvent   = _button_handleEvent
      this.performClick = _button_performClick
      return this
   end function

   function _button_handleEvent(event as Object) as Boolean
      buttonCodes = bslUniversalControlCodes()
      if event.getInt() = buttonCodes.button_select_pressed
         m.performOnClick()
         return true ' We handled this event
      end if

      return false ' We didn't handle this event -- it should be passed to others who may wish to handle it
   end function

   function _button_performClick() as Void
      ?"Button was clicked!"
   end function

   ' -----------------------------------------------------------------------------
   ' Run Loop

   function runloopCreate() as Object
      return {
         _exited : false
         _root    : componentCreate()
         run       : _runloop_run

         getRoot: function() as Object: return m._root: end function
      }
   end function

   function _runloop_run() as Void
      while not m._exited
         event = m._messagePort.getMessage()
         if event <> invalid then m._root.handleOrForwardEvent(event)

         ' ... snip other run-loop stuff like drawing ...
      end while
   end function

TYVM ... for your time and code!

I need to go over your framework 42 more times, but I'm starting to see similarity in what I've done.
( Is it common to create a framework and then become fuzzy on how it works? :oops: )

But that's part of the reason for the thread. I have a working menu that is non-modal, but it isn't quite the same as a roMessageDialog in look-n-feel. Thus the attempt to initially use and now attempt to roll my own. I am reconsidering this and wondering if it wouldn't be easier to try to spiffy up what I already have working, but due to some "genius" reasoning on my part, my_menu and my_textbox are tightly integrated. Saved time / code before, more discomfort today. 😛

peace & 42

"dev42" wrote:
Is it common to create a framework and then become fuzzy on how it works? :oops:

In short, yes. That's why separation of concerns and good documentation is critical to good architecture. If you have undocumented assumptions or dependencies, chances are in 8 months you'll forget about them.

"dev42" wrote:
Saved time / code before, more discomfort today. 😛

Been there. Sounds like time for a refactor! 😄

I try to revisit work done a few weeks back, see if my documentation is clear to me, and if not, refigure what I've done (since it's not THAT old I can get "back into it" pretty quick), and improve my notes accordingly.