Subj : Javascript weirdness To : Digital Man From : deon Date : Mon Apr 18 2022 20:52:11 Re: Javascript weirdness By: Digital Man to deon on Sun Apr 17 2022 09:17 pm > > Yeah for me, its not happening on every msg area - on my laptop I only have 4 or 5 with messages in (and a low number of messages), > > and it's only happening to this one message base. > > Try using a simple script, like the one I pasted? Your script is not that different to mine, but I did try it anyway in case it was the conditional handling. Still the same result :(. Perhaps I send you the msgbase and you see if you get the same result? It'll have some messages tagged, and the 2 that wont. > Not without some padding to accomodate the extra data having been assured to always be there. And then there would still be *some* > limit > to how much additional data (e.g. the length of the tags header field data) you could add. I could add an option to always pad headers > for > specific message bases, if this is something you need. I'm not clear on the use case. It was expected that a message author would add > tags > to their message at the time of posting their message, if they wanted to. Not after. So my use case is for my viewdata (videotex) shell that I've been chipping away at the last year or so. With viewdata, everything is a "frame" identified by a number - ie: *642# would display page 642 to the user. My goal is that the content of frame 642 is a message in a mailbase. I'm also wanting to enable echomail messages to live on a static page, so for example, *10010051234# would pull out message 1234 from the zone 0010 echomail area 05. Thus as a message is tossed, a post activity would tag the next message in that echoarea as 1235, etc. I thought that keeping the frame numbers in the message base (via the tags attribute) was workable, since that isnt really used at all anywhere else, and I dont need to manage it outside the message base (and keep in sync with it). I am only aiming to add 4 bytes (a 4 digit page number), so it would be useful to pad the space to ensure that there is always room. I was going to ask if it was too hard to "relocate" the message header, if there isnt room in the current block to hold those extra 4 bytes, and the next block is occupied (not sure if that is an option). On a related question, if I set a message area to hold 10000 messages, and the 10001 message comes it, message 1 is eligible for deletion - how is that determined? By the lowest "number", the lowest "when_imported_time" (is "when_imported_zone_offset" considered as well?) or some other field(s). ....лоеп --- ю Synchronet ю Alterant | an SBBS in Docker on Pi! * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .