annoying bug

There's an interesting bug! I don't get exactly the same result, but it definitely screws up the box. I only get invalids if I keep pressing Ctrl-C. Issuing an ECP launch/dev command oddly enough took me back to the main menu, but nothing works except "Settings". I can preview a screensaver, but it's obvious that something is eating up cycles and I can't get into the screensaver's custom settings. This is a case where the reboot remote sequence comes in handy.

-JT

We ran into that non-functioning home screen problem about once a week while developing KidPaint. I think it was a combination of crazy code and a less mature environment at the time. I haven't seen this particular behavior in months now.

kbenson, I've seen the behavior you described as well and as you said I haven't seen it in months either. It's as if the main application thread doesn't get properly killed. I was never able to come up with a repeatable example, until now. :mrgreen:

-JT

The port is a global m.port, defined like this (totally untested code but similar):

sub main
v=init()
v.exec()
end sub

function init() as object
return {port:createojbect("romessageport")
           scrn:createobject("roposterscreen")
           exec:dostuff}
end function

function dostuff()
m.scrn.setmessageport(m.port)
stop
end funtion

then ?m.port

More annoying port stuff:

given a port m.port

and an object like a springboard

p.setmessageport(m.port)

x=p.getmessageport()

?x

roku now needs to be rebooted....

While crashes and reboots certainly aren't ideal, why exactly are you trying to print message ports to the console anyway?

According to the component reference, x=object.GetMessagePort() should tell me what if any port the screen is set to. Instead if results in having to reboot when I print.

I"m trying to figure out why I'm not getting any messages on a port when I've set the screen to point to it. The port exists (global), the screen exists (local) both exist in the current context. Once I hit the message loop, nothing further happens unless I hit break, or the home button.

- Joel

Oh, also, I just felt like bitching and moaning.

- Joel

"jbrave" wrote:
According to the component reference, x=object.GetMessagePort() should tell me what if any port the screen is set to. Instead if results in having to reboot when I print.

All I can find in the component reference is that it says it returns the message port. The distinction in implied use is subtle, but there. You aren't supposed to print a message port. Printing it would probably just give you a listing of it's object type.

I"m trying to figure out why I'm not getting any messages on a port when I've set the screen to point to it. The port exists (global), the screen exists (local) both exist in the current context. Once I hit the message loop, nothing further happens unless I hit break, or the home button.

Are you creating message ports as needed, or passing around existing ones? I'm pretty sure the purpose of the GetMessagePort() method is to make it easier to access existing ports for re-use.

was trying to pass one around. As it turns out, if you don't create a button on a springboard, it appears you don't get any messages period, so the problem is essentially solved.

- Joel