Naming array keys for WordReport!!

[wayi]

Although for my own apps I generate reports as PDF files, I'm helping a colleague who insists that these be editable files. Thanks to mentions elsewhere in this forum, I found Curry Kenworthy's clever WordReport extension. It necessitates passing an array that is used to fill in the items of a preconfigured MSWD template.

Despite the fact that my LC array includes literally over two hundred items, this generally has been yielding an accurate printout. However, there've been some very perplexing glitches.

According to Curry's reply to my inquiry, LC array keys are inherently case sensitive. However, I found that -- for example -- the generated report inserted the same value for the keyed "m" as for the keyed "M". Once I changed the former key to "nm" (in both the template and the code) the correct value was displayed.

(BTW, although I don't think it would matter, I did set the caseSensitive property to true in the handler.)

Although all of the keys employed in my array are already unique, I suppose that I can rename these to be even *more* unique -- if that makes any sense at all as a concept.

I'd appreciate feedback from anyone who has encountered glitches in naming array keys, whether or not related to the WordReport extension.

Thanks.

[bogs]

I think this might be better served in the intermediate part of the forum, since it seems a little above a complete beginner level, but I'll leave that for smarter people to figure out

I look forward to seeing the answer to this question, as it relates to arrays myself.

BTW, although I don't think it would matter, I did set the caseSensitive property to true in the handler.

Although all of the keys employed in my array are already unique, I suppose that I can rename these to be even *more* unique -- if that makes any sense at all as a concept.

It makes sense to me, so much so that I always shoot for it whenever I use an array. If something that simple corrects the problem, I'd certainly roll with it.

*Disclaimer - I am not familiar with (and wasn't even aware of) Curry Kenworthy's clever WordReport, so I have no idea of the way it works internally. Thanks for introducing a new toy to my attention

[mrcoollion]

Just tested it in a button with the script belaow and the answer always shows "This is capital M" .
So without changing any settings an array node name is not case sensitive i would say?!
But with caseSensitive set to true the answer shows the two different tarray data. Meaning that in this case array node name is case sensitive.

Working with LC 9.5 dp 1 on Windows 10.

Code: Select all

on mouseUp
   put "This is lowercase m" into tarray["m"]
   put "This is capital M" into tarray["M"]
   --
   answer tarray["m"]
   answer tarray["M"]
end mouseUp

With caseSensitive set to true

Code: Select all

on mouseUp
   set the caseSensitive to true
   put "This is lowercase m" into tarray["m"]
   put "This is capital M" into tarray["M"]
   --
   answer tarray["m"]
   answer tarray["M"]
end mouseUp

Regards,

Paul (mrcoollion)

[kaveh1000]

Hi all

This thread was useful for me as I have case sensitive keys (and unicode chars) for an array and caseSensitive is what I needed. But I have a problem that has been driving me mad, in that a value that I set to a key changes case if there are identical keys with the same letter, but different cases — so in my example, we have keys: Á and á. I have produced a minimal stack, roughly following the script of Paul. The script is:

Code: Select all

on mouseUp
   set the caseSensitive to true
   put "á" into tUnicode
   put "a" into tRoot
   put tRoot into tarray[tUnicode]["root"]
   
   put "Á" into tUnicode
   put "A" into tRoot
   put tRoot into tarray[tUnicode]["root"]
   
   --
   answer tarray["Á"]["root"]
   answer tarray["á"]["root"]
   
   put tarray["Á"]["root"] into fld 1
   put return after fld 1
   put tarray["á"]["root"] after fld 1
end mouseUp

(Yes, I should have a function, but not worth it for this short script!)

All works well, until you look at the variables list and you see that both results have a "root" of lower case "a" — see attachment.

In this minimal stack, it is only when you look at the variables that the difference is visible, so I thought it is just a rendering problem. But in my larger stack, the value of both really is "a". I could not replicate that here.

Any idea what is going on please?

[dunbarx]

Hi.

LC does not care about case when building arrays.

Code: Select all

on mouseUp
 set the casesensitive to "true"
   
   put "x" into myArray[a]
   put "y" into myArray[A]
end mouseUp

You get only a single key, "a", and it has a "y" in it, since that element overWrote the original "x",

Craig

[kaveh1000]

Hi Craig

But pls see Paul's script where he is using CaseSensitive precisely to have case sensitive array keys, so there are two keys: M and m. And the dictionary says:

The caseSensitive also affects custom property names and array key names.

If you look at my stack, there are definitely two elements in the array, with keys Á and á, but the case of the "root" of each has been set to same.

[bogs]

Kaveh,

In Craig's defense (prior to Lc 8.x for sure) the results of using caseSensitive were... vague, let's say

I think I can also add that for some reason, it depends on how you test it out as well, at least on 'nix. The way I ran this test -

1.) fired Lc 6.5.2 on a fresh boot
2.) put the following into the multi-line message box:

Code: Select all

set the casesensitive to true
put "x" into tArray["a"]
put "y" into tArray["A"]

put the keys of tArray

As Craig states, this returned a only, not both a & A, as it should have. I went back and read Paul's post, and saw he was using 9.5, and, knowing as I do that things can change, tested in 8.0.1 where amazingly, the keys returned a & A. Go figure!

I went and cracked open 7 back down to 6.x to see if I could find out where the change had taken place, but for some reason, it now worked in *all* of those versions

So, while it does work consistently post 8.x, Craig has been using this since before Lc existed and can be excused for knowing things that may no longer be true, if you see what i mean. If you were doing something, and one method didn't work for 20 years, I am sure you would not be thinking of that method now.

[kaveh1000]

I know both you and Craig know what you are talking about! Thanks for your time both.

I am now wondering if I should make things simpler. So I have an array that I am reading in and it has alphanumeric keys. Perhaps best if I just add a set of numeric keys, so a new "column" at the start. then there is no problem about case sensitivity.

So what is the simplest way of taking an array and adding a set of ascending numbers? I should know but I am not good at arrays!!!

[bogs]

Compared to Craig, I know less than nothing hah hah, but thanks anyway hahaha...

I am now wondering if I should make things simpler.

Well, I said up there, I always prefer simple

It is too bad that the tutorial I just uploaded was hosed during the upload, it gives a pretty simple explanation of arrays

So what is the simplest way of taking an array and adding a set of ascending numbers? I should know but I am not good at arrays!!

Well, if you have the amount of information you want to put into the array in a variable of some kind, why not just use a incrementally increased repeat loop? Off the top of my head (not tested) something like -

Code: Select all

# assumes your variable is named tmpList and is 1 array item (or whatever) per line :P
repeat with x=1 to the number of lines of tmpList
	put line x of tmpList into tmpArray[x]
end repeat

I suspect you could turn that into a function and have it work with any list, if all your looking for is numbered keys.

[bogs]

Actually, that code did need some modifying, but this works.

Code: Select all

repeat 20 times
  put random(20) & cr before tmpNum
end repeat

put tmpNum
put 1 into tmpArrayKey

repeat with x=1 to the lines of tmpNum
  put line x of tmpNum into tmpArray[tmpArrayKey]
  put (tmpArrayKey + 1) into tmpArrayKey
end repeat

# answer the keys of tmpArray
answer tmpArrayKey

Hmmmm....

[kaveh1000]

That's great bogs. But what if I am starting from an array, so I already have a 2D array:

tArray["key1"]["value"] = "One"
tArray["key2"]["value"] = "Two"
etc

I want to transform this to:

tArray[1]["key1"]["value"] = "One"
tArray[2]["key2"]["value"] = "Two"
etc

then my new keys are 1, 2, etc that are simple to manipulate. Does this make sense?

Perhaps I could combine, then put 1, 2, before each line, then split.

[bogs]

then my new keys are 1, 2, etc that are simple to manipulate. Does this make sense?

Not to me, but I'm going to be late for an appointment and don't have time to reason it out, the format I set it in already is numbered like that. Maybe someone else understands what your asking better?

If your talking about the order the keys show up in, there is no order in the keys. You can put the keys into another variable, and sort it, which will give it an order, if you want. Seriously, before I re-upload the video, go look at the array tutorial in the playlist and see if the explanations there help you.
https://www.youtube.com/playlist?list=P ... irZwllQUTw

[dunbarx]

Hi.

It would be astonishing to me that the several versions of LC, from 6 to 9, changed the way arrays work in such a fundamental way. How did this not break just about every handler ever written?

And another thing, when I do this:

Code: Select all

on mouseUp
   set the casesensitive to true
   put "UP" into tArray["a"]
   put "DOWN" into tArray["A"]
end mouseUp/code]

I get:

A   UP
a   UP

I am not sure what is going on.

Craig

[bogs]

Not sure what is going on there either, Craig. That is in 9.5 ? (Highest I tested was 8.0.1)

Oh wait a minute. I only tested caseSensitive to differentiate the keys. Thats a big DOH! on my part I never completely tested it to see the values

Teach me to try and answer a question in a rush

[dunbarx]

Bogs.

9.04.

And I only included it because you made me.

I rarely go back. But you do, and find all sorts of things that depend on the LC version. I have a feeling that testing will show up a bunch of odd stuff...

Craig