+/IM.logon (login mods)

[ThaDoctor72]

Writing data skewed by one record. On the screen when editing a login instance, it looks correct, but after saving, if you go back and look at the changes, the data is skewed. Example. add 3 modules, and configure:

# name acs 1. news 1023 2. last 1023 3. grf 1023 Save the changes, then go back and edit and it will look like

# name acs 1. news 1023 0 2. last 1023 0 3. ^

The content of e.loginmods is 3 last 1023 grf 1023 news 1023

Before I edited it, the content (as is on the R2 disk set) 2 last 1023 news 1023

Update: it appears to be the write routine in +/IM.logon, because all 3 areas are affected in this manner. Maint mods, login mods, and quicklist. Haven't tested wall ads, but I imagine it would be the same. In my humble opinion, I think just adding another print#2 statement in between the variables will cure it. Change 4040 fori=1tobr:print#2,tt$(i)r$a%(i):next:close2:return to 4040 fori=1tobr:print#2,tt$(i):print#2,a%(i):next:close2:return I'm guessing someone is using r$ as a soft carriage return but doesn't get translated that way when writing the file for some reason. Either that, or r$ was never loaded with the chr$(13) during the startup routine. Hell, perhaps the second print#2 statement can be mitigated by adding chr$(13) in it. Either way, that's beyond my pay grade.

** UPDATE (again) I changed my +/IM.logon line 4040 to read 4040 fori=1tobr:print#2,tt$(i)chr$(13)a%(i):next:close2:return and it worked like it should. I'm thinking someone just forgot to set r$=chr$(13) during init. I went further to just declare it in the master file +.IM at line 3000 with r$=chr$(13) and it cured all 3 of the areas mentioned. I know we're all about saving memory space, but cmon. :)

[x-tec2017]

Tested on Hyperdrive, Thunderdrive, uIEC/SD2IEC and WinVICE. Could not duplicate problem. Looks like you got a bad conversion of the IMG2.0 R2 D1.D81 file when you copied it to your working drive. I'm looking at the original file that I uploaded and in +/IM.logon, line 4040 reads: 4040 fori=1tobr:print#2,tt$(i)r$a%(i):next:close2:return

You were missing the r$ after tt$(i) r$ is always defined as chr$(13) but you knew that, right? Anyways, good catch. I will download the .d81 file from facebook and compare it to the one I uploaded.

[x-tec2017]

Nothing wrong in that file line 4040 in the one I just now download from facebook.

[x-tec2017]

OK, I had to come back to this one as well after re-reading the issue and thinking about it for awhile. I know that in 1.2 we were always defining r$=chr$(13) all over the place but in 2.0 it's not supposed to be that way. During bootup, line 3064 in the im file sets r$=chr$(13) as a reserved variable. It should never be changed. So, there should be no reason to have to define r$ in every module that is run, in fact, none of the +/IM. modules define r$ and even the mother program, +.IM, doesn't define r$ so probably, somewhere among all the files included in Image 2.0, there might be somewhere that someone (even myself) might have defined r$ as a different value than chr$(13). It would have been in something that was run prior to entering the IM section and could explain why you saw the problem and I didn't.

Wow! Finding that might take awhile. Do you remember what you ran prior to going into the IM section?

[ThaDoctor72]

A little bit of everything, but I think that might be my fault. While I was porting over my responsive prompt feature, I had written a line (it's gone now) that changed a handful of variables over to singles, thinking that none of the singles were system reserved. r$ was one of those variables. I didn't have an updated variable or jumpcode cheat sheet, so I had wrote that file to display a$ thru z$ at every possible prompt that shares the (gosub1006) prompt. After I made my discovery and took notes, I removed the line that redefined variables, so I should be back to stock now. But while I was testing those modules, that line was active.

[x-tec2017]

Yeah.... That would explain things. I just spent the past couple of hours checking files included in the 2.0 R2 revision using the Lt.K find /r$=/ command. None of the 2.0 programs had it in there except for when it was defined in im line 3064. I did find several 1.2 conversion +.files that had hits but they all defined r$ as chr$(13) I think this issue can be closed.

[ThaDoctor72]

Agreed. For future reference would it be better to have chr$(13) or F6? (the reverse K) I figured out what I had done after I tried to use the editor (WF) and none of the dot commands would work. That's stored in a$ and s$.

Could really use a cheat sheet. (hint)

[Pinacolada64]

I think the standard has been when you're writing data to a disk file, use r$ between records (a final carriage return should be output when writing to a REL file, but I'm not 100% certain of this). & output statements can use {f6}.

Could really use a cheat sheet. (hint)

A cheat sheet to what?

Have you guys seen the 1.2 cheat sheet I started? I uploaded it to Facebook a while back. Never saw any feedback about it.

[ThaDoctor72]

Yes, I saw it. But it's not entirely accurate for 2.0. Many of the consistent variables are the same, but there are things like mp%, mt%, and tu$ that were not referenced. I do use it regularly when I'm working on 1.2 items especially jump tables and lightbar calls, but I'm awful about remembering feedback.

[x-tec2017]

This issue should be closed. I think only the originator of the issue can close it. (Jay)

[ThaDoctor72]

Yep, been out of town lately. Closed.