Using ECP as a PostMessage replacement

Y U no use?

port.PostMessage(msg as object) as void

Good Point! I should have been more clear. Actually I almost went in to edit this post to remove the PostMessage and be more specific. But I really need to broadcast since I use multiple ports. Although only one port would be interested, but not always the same one. So my question is really a broadcast to whoever may be interested, at times no one is. And if there is an IfMessagePort.PostMessage, then I'm not aware of it

There is an ifMessagePort.PostMessage but it's not documented and is intended mainly for NDK apps. Couldn't you just push your string onto a list and check the list before each Wait?

--Mark

"NewManLiving" wrote:
So my question is really a broadcast to whoever may be interested, at times no one is.

Hmm, and ECP /input would help with msg broadcast/multicast? I don't see how, since it's just a message that will be posted to the (1) topmost screen port.

Ostensibly - if you wanted to avoid the undocumented function - you could write a wrapper that includes/uses a roMessagePort - and as part of its new getMessage() function it drains port's queue into its own (to preserve sequential order), appropriately mingling it with side-injected messages, something like (sketching, with errors):

function newMyPort():
  return { port = createObject("roMessagePort"),
    getMessage = function(): ._xfer_pump(): return m._queue.shift(): end,
    postMessage = function(obj): m._xfer_pump(): m._queue.push(msg): end,
    _queue = [ ],
    _xfer_pump = function(): msg = m.port.getMessage(): while msg <> invalid: m._queue.push(msg): msg = m.port.getMessage(): end: end, 
  }
end

my_port = newMyPort()
screen.setPort(my_port.port)

... it's OOP-pretty but won't solve your case that you just expanded on. Maybe you should dig deeper and explain why multicasting?

To answer marks question. I use getmessage as I always have at least two timers going and I am trying to avoid exactly what he is suggesting

To answer yours it would not be multicasting in the strict sense since as I said there would always be only one interested port. But that port may change. Here is the scenario: I have three types of grid designs; active, semi-active/passive and fully passive. My question is more related to the fully-passive.

In order to keep things flowing as smoothly as possible especially on the ROKU 1 I use fully-passive
This assumes that if the user is scrolling away from the displayed rows then they are looking for something else
In the fully passive paradigm once the user scrolls past the display area and the fetch-ahead buffers then the placeholder bitmap is displayed until the scrolling button is released. At that time the display and fetch-ahead indexes are recalculated, the former textures outside the indexes are unloaded and the new texture requests are sent asynchronously. This keeps memory allocation fixed no matter how many textures there may be. However, there is nothing preventing the user from immediately scrolling , even fast scrolling, away from those indexes even before all the new textures arrive. If I allow the textures to arrive then I get the home screen studder problem which I dislike. So on the flip side, if the user re-initiates scrolling all textures that are states < 2 are cancelled. All this takes place asynchronously so there is only one global event handler to make sure this complex mess comes together nicely. I call this object the cache manager. To further complicate squeezing asynchronous events into a single-threaded environment, there is no telling when the textures arrive. There may be stragglers that for some reason or another do not arrive so quickly. You can see this happen even with the built in grids. So say the user has stopped scrolling , new textures requested, but not all have arrived before the user selects a grid cell which opens up a dialog. Obviously the dialog must also monitor the texture port and forward the event to the handler where it is unpacked and processed so the user may observe textures popping into the grid even while the dialog is open above it. I will stop here but there is much more, not to mention problems with textures at state 2 which Is downloaded but not yet ready. But I won't even get into that here. So you can see a more effecient way to handle possible exceptions from the event handler is not to have to keep checking return codes from the event handler. broadcasting or even posting for me is a much cleaner solution