Hi All
The right-click View Structure selection doesn't seem to take any entries below MAP3 into account.
Is there a reason for this?

The "Position" column would be very useful but I do use MAP5's & 7's so unless these are included in the calculation it's of limited use.

Barry

Hi Barry,
Leave it to the one who posts a single message every few years to figure out how to sneak one on to the BBS without anyone noticing. That said, I remember running into a variation of this problem with a structure that didn't View properly while in Savannah, but couldn't put my finger on what was unusual about it. I suspect now that it may be related to there being a gap in the levels.

I'll open up a Western Front on Firmaware to make sure the message is properly received.

By the way, I'm glad to hear you made it back ok. I'd been scanning the lists of victims for your name, after that last spate of Manatee attacks.

Hello Barry,

Apologize for my silence on this subject, it happened because, one of these days when login on the BBS all the "lamps" were ON (it happens sometimes for any unknown reason), I searched for the last posts, and I confess that didn't pay much attention into the "Editor" topic considering that it has been silent for a long time.

Regarding to the issue you reported, I create a structure with 7 levels, but didn't notice any problem:



Can you reproduce here, or e-mail me the structure you're using?
There is always the possibility of any combination could break the View Structure logic.

I don't have a sample ready for you, but I think the issue occurs when there are gaps in the structure, i.e.

map1 var1
map3 var2
map5 var3

Hi Jorge

I think Jack may be correct - gaps in the map level seems to cause the problem.
Try this:
MAP1 NOM'REC,S
MAP2 NOM'RECX,X
MAP3 NOM'KEY,S
MAP5 NOM'SKEY,S
MAP7 NOM'CO,S,1
MAP7 NOM'CC,S,4
MAP7 NOM'CODE,S,6
MAP3 NOM'REPKEY,S
MAP5 NOM'COR,S,1
MAP5 NOM'CCR,S,4
MAP5 NOM'REP,S,5
MAP3 NOM'DESC,S,36

Structure result:
Variable Type Size Position
NOM'REC S 1
NOM'RECX X 1
NOM'KEY S 1
NOM'REPKEY S 1
NOM'DESC S 36 1

Barry

Hi Barry,

I must confess that even didn't know this was possible to do
1) skip intermmediate MAP levels;
2) define Type for variables with sub-level (e.g. map1 NOM'REC,S)

I take the chance to ask if this brings any benefit, or even if it's an advisable practice.

So, the result should be:
In fact, the above suggestion is different from what the Editor currently does, now it doesn't display the size for the top level variables so, there are two questions here:
1) Does the solution above is what should be expected
2) Should the View Structure display the size for the top level variables (e.g. NOM'REC, NOM'RECX,...)

Regards

Hi Jorge

Any benefits... hmmm!

1. Skip map levels.
To be honest I can't remember now why I started doing this. I can only think it was so it would be easy to slot in extra maps to refer to a small group of other variables.

2. Define types for sub-levels.
Absolutly! Use this all the time. S type allows clearing a record or array to all null easy and X type to copy a section of a record that may contain null fields. How do you do it otherwise?

As for the solution.
Yes, your example is what I would hope to see.

Barry

Everything clear now, thanks.

Regarding the "copy" issue, I guess that I don't care too much about those tricks and prefer to always copy each variable along the structure; as for "clearing", now I use:

structure = fill(chr(0),sizeof(structure))

I'll publish an Editor update asap.

Regards

My hat's off to you Barry, for coming up with a technique I hadn't even thought of.

I would caution you, however, about the major downside of using a string type for your top level record variables: assignments from the variable will be truncated at the first null, while assignments to it will have the first null extended to the end of the variable. This is not what one usually expects when assigning one structure to another.

For example:

MAP1 SREC1,S
MAP2 S1'COST,F
MAP2 S1'PRICE,F

MAP1 SREC2,S
MAP2 S2'COST,F
MAP2 S2'PRICE,F

S1'PRICE = 1.23
S2'COST = 0
S2'PRICE = 99.99
SREC1 = SREC2
PRINT "SREC1 after assignment: "
PRINT "S1'COST = ";S1'COST
PRINT "S1'PRICE = ";S1'PRICE

My guess is the most programmers would look at this code and expect S1'PRICE to be 99.99 after copying SREC2 to SREC1. But if you run the above test it will come out 0, because the first null byte in S2'PRICE will terminate the string copy operation, and the remainder of the SREC1 structure will be set to nulls.

The technique I always used (until someone pointed out the fill(chr(0),sizeof(struct)) technique was to map a string overlay on top of the regular unformatted record, i.e.:

MAP1 REC
MAP2 COST,F
MAP2 AMOUNT,F
MAP1 REC$,S,12,@REC

This way you can use REC when you want to perform normal raw record transfer operations, and REC$ when you want to have the string behavior.

But the fill() function is probably even cleaner, eliminating the extra map statement.

Hi Jack
I understand the restrictions of using string variables (null termination) which is why we use both s and x types for every record.

My version of your examples would be:

MAP1 SREC1,S
MAP2 SREC1X,X
MAP3 S1'COST,F
MAP3 S1'PRICE,F

MAP1 SREC2,S
MAP2 SREC2X,X
MAP3 S2'COST,F
MAP3 S2'PRICE,F

SREC1X = SREC2X

and

MAP1 REC,X
MAP2 RECS,S
MAP3 COST,F
MAP3 AMOUNT,F

RECS = ""

... different strokes for different folks ...

Barry

Hi Barry,

Just a quick note to let you know that we have already done the requested changes in the View Structure, but it will not be published yet, give me a couple of days to test everything.

The reason for this caution is not because of the changes in View Structure, obviously, but because we had to include it in the currently published release, where we add some (very) beta new features.

Barry, I must admit that your method for handling the dual format S/X issue may be the most elegant of all, since it eliminates the need for any overt size or cross-referencing (which could be broken when updating the structure later). I probably would have reversed the order so that the X version was at the top level, and maybe used the $ suffix on the S variable to make it completely obvious when you see something like SREC1$="" buried in the code, but it's just as you say...

It also illustrates the genius of the MAP statement concept - so simple but so flexible and powerful at the same time.

While on the issue of fill(). How does XCALL FILL differ from fill(). We use:

I've not noticed that this doesn't work as expected, so is there something I need to watch out for here?

By the Way, there isn't really any useful info on xcall fill or fill() in the .CHM.

Hi Jorge

Hopefully you see this new post to an old topic.

Did you ever release this change to View Structure?
My Editor (1.6.118.69) still doesn't work as discussed here. I've tried "Check for Updates" but that says "No Update Required!”

As I said previously this would be very useful, as I have to work out offsets by hand for many variables.

Thanks
Barry

Ooops!

Sorry about this, I'll do my best to get a fix for this today.

Now if your still looking at the View Structure, I noticed a while back a view on 2 dimensional arrays show as:

MAP1 TEST'RECORD
MAP2 TEST'FIELD(2,12),F,6

calculated as:

Hi Steve,

I came here to give an explanation to Barry about the status of this topic so, let me start with it...

The issue of the View Structure not handling correctly non-sequential MAP statements, was solved on the next day of your reminder but, after publishing the patch, we noticed that the Editor package was not correctly built regarding to the compatibility of all modules, there are a mix of old and new Editor version.
It's not easy to explain all the details behind this situation but, while trying to put all the parts together, I decided to inform about this.
Apologize about that, we will try to fix this as quick as possible but, the problem is more about being sure that nothing else is broken.

Steve, thank you for the additional note, definitely bi-dimensional arrays are not well covered in View Structure, to review when we get back to the right track.

Thanks for the update Jorge.

Barry

An alturnative layout for this original above.

MAP1 NOM'REC,S
MAP2 NOM'RECX,X
MAP3 NOM'KEY,S
MAP5 NOM'SKEY,S
MAP7 NOM'CO,S,1
MAP7 NOM'CC,S,4
MAP7 NOM'CODE,S,6
MAP3 NOM'REPKEY,S
MAP5 NOM'COR,S,1
MAP5 NOM'CCR,S,4
MAP5 NOM'REP,S,5
MAP3 NOM'DESC,S,36


Is this layout from the old Alpha Accounting.

MAP1 NOM'RECX,X ! unformatted for read/write
..MAP3 NOM'KEY,S
....MAP5 NOM'SKEY,S
......MAP7 NOM'CO,S,1
......MAP7 NOM'CC,S,4
......MAP7 NOM'CODE,S,6
..MAP3 NOM'REPKEY,S
....MAP5 NOM'COR,S,1
....MAP5 NOM'CCR,S,4
....MAP5 NOM'REP,S,5
..MAP3 NOM'DESC,S,36

MAP1 NOM'RECX2,@NOM'RECX
.MAP2 NOM'REC,S,57 ! overlay a string var

NOM'REC="" ! clears the record

Later,
RJ

Hi RJ

No connection to Alpha Accounting.
If it looks similar its just coincidence.

Barry

Hi Barry,

MAP1 NOM'RECX2,@NOM'RECX
.MAP2 NOM'REC,S,57 ! overlay a string var

NOM'REC="" ! clears the record

I meant that my suggested form of overlay with a MAP2 of type "S" is from Alpha Accounting.

The more I look at your form, the more I like it.

Later (Hasta Luego here in South Florida)
RJ