Subj : MsgBase first_msg property.
To   : Digital Man
From : deon
Date : Mon May 09 2022 09:32:59

  Re: MsgBase first_msg property.
  By: Digital Man to deon on Sun May 08 2022 11:28 am

 > I would be adverse, yes, as static variables are shared among on threads (e.g. nodes) and if you opened 2 message bases, that variable would be stomped on by the second opened message base. That's not going to work.

Ahh, OK, of course ...

 > The smb.status header is not cleared when the msgbase is closed. But that's sort of what I was proposing: it should be. Or at least js_msgbase_get() should return 'undefined' for those properties when the message base isn't open to let you know that you've done something unexpected.

I guess I'm not understanding why it "should be". For me, it still provides value when the message base is closed, and programatically I can know if those values are current.

I probably could delay my closure of the msgbase until later (and I'll have to if you do go down that route) - but hestitant too, as I am not sure what other things may be locked out if I do and I'm too slow...

 > I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.

Thanks, I was going for what you were doing but couldnt figure out how first_msg would default to zero if the attribute was read and the msgbase hadnt been opened yet. How are you getting that? I thought with c++ it could get some random number (from the contents of the memory location that it's pointer was pointing too...) hence why I tried static.

Appreciate your help.


....лоеп

---
 ю Synchronet ю Alterant | an SBBS in Docker on Pi!

.