Not a number is a number, problem

[bogs]

Not sure I follow you, AxWald ?

If your talking about how I built tLine...

Code: Select all

put the text of the mouseLine into tLine

   repeat for each character x in tLine
 	put charToNum(x) & "," after tLine
	put tLine
   end repeat

How else would you build a variable where your testing individual items? Or are you saying you never change the variables you use? I don't get it.

[dunbarx]

I read Axwalds query differently, that the index of a loop variable was changed midStream:

Code: Select all

on mouseUp
   put "" into fld 1
   repeat with y = 1 to 10
      put y into line y of fld 1
    --  if y = 5 then put 9 into y
   end repeat
end mouseUp

If you run this, you get a list from 1 to 10. If you uncomment the fourth line, you get something rather different. In any case, it all seems straightForward.

Craig

[bogs]

I must be incredibly dense this morning, but Craig, your post makes no sense to me in the context of what I wrote for code, or how to interpret AxWald's post.

My code builds a variable using a loop.

Your code changes the parameters of the loop variable quite blatantly when un-commenting the if statement. Certainly if I wrote a loop that modifies a variable based on a conditional statement, I would not be expecting it to deliver a variable that would be the same without the conditional statement. My code doesn't do any thing like that, so........

How is this an explanation of anything?

[bogs]

I actually figured out what AxWald was talking about, Thanks for trying Craig.

@AxWald, thank you, as well, it took a while but I get it now

[jacque]

This doesn't address your character problem but if you want to know if a line is virtually empty you can use:

Code: Select all

the number of words in line <x of fld y> = 0

because white space doesn't count as words.

[bogs]

This doesn't address your character problem...

You have known me (on the boards) for about 3 years now, certainly nothing can address my character problems
(To any one reading this, I am JOKING*, I'm pretty sure Jacque gets it though )

I *think* AxWald got me past that, I made a logic error in how I believed the 'for each' worked. Oh well hee hee.

By white space, I assume you mean tabs and spaces? I had a funny experience with those too, setting text styles (which was what brought up the whole 'selected' thingie from a bit ago).

I finally figured out my own route for it, which used 'set the style of the last word' and worked, but funnily enough, the style was *sometimes* applied to the space or spaces following the last word. I'm still trying to figure out how THAT one works but, I did figure out that if I instead put :
'set the style of characer 1 to -1 of the last word'
..then the spaces don't get styled. Annoying, but not show stopping.

* Well, not really, there is nothing that addresses my character problems

[jacque]

I won't comment on your character, Bogs.

Text characters though...Yes, spaces, tabs, carriage returns, and anything else that isn't visible to the eye is called "white space" when we're talking about text.

It isn't clear to me what issues you had with setting textstyles, but it kind of sounds like you're wandering into the "what is a delimiter" area and I don't think I want to go there right now. It has been the subject of passionate discussion in the past.

[bogs]

It isn't clear to me what issues you had with setting textstyles, but it kind of sounds like you're wandering into the "what is a delimiter" area and I don't think I want to go there right now. It has been the subject of passionate discussion in the past.

Well, least I won't get heated about it haha. This is what I'm talking about....



In places (see arrows) the text styling runs not only over spaces, but in some cases halfway into other words. In other places, it does not. Goofy stuff.

I won't comment on your character, Bogs.

That is because you are much too genteel, except with krill

[AxWald]

Hi,

Not sure I follow you, AxWald ?

Oooops. Sry for puzzling you, should have explained better.

Well, look at this:

Code: Select all

   put the text of the mouseLine into tLine     --  tLine be "aa"
   
   repeat for each character x in tLine
      --  first iteration: x = "a"       ==============  PseudoCode from here!!!
      put charToNum(x) & "," after tLine
      put tLine                                 -->  "aa97,"
      
      --  second iteration: x = "a" again
      put charToNum(x) & "," after tLine
      put tLine                                 -->  "aa97,97,"
      
      --  third iteration: x = "9" now
      put charToNum(x) & "," after tLine
      put tLine                                 -->  "aa97,97,57,"
      
      --  And so it runs forever 'cause tLine grows faster than you can compute it.

In case LC actually refreshes tLine (as above) you just created an infinite loop:
You start with n chars in tLine, and in each iteration you add at least 2 (charToNum(x) & ",") more chars to it.

Since you don't talk about that, it's to assume that LC actually creates a copy of tLine here:

Code: Select all

   repeat for each character x in tLine         --  another tLine for the loop?

But now there are 2 variables "tLine"! Which of these to "put"?
LiveCode may have a hard time guessing what you're telling it to do, and may start feeling annoyed
("What the F-word? Can't you M-word code something computable? So eat this, S-word!").

You see? Thus:

I'd expect strange results :)

Have fun!

[bogs]

Oooops. Sry for puzzling you, should have explained better.

's ok, I eventually got it because, due to what you wrote, I broke it out and tested with a number of vars until I reached the conclusion you presented

[jacque]

In places (see arrows) the text styling runs not only over spaces, but in some cases halfway into other words. In other places, it does not. Goofy stuff.

I haven't seen that behavior. We'd need to know how you set the text styling to see why it did that. Was it scripted? Manually selected? If scripted, can we see the relevant part?

[bogs]

Sure, this is all in a testing phase at this point, so the code is both ugly and inefficient (and I'm not looking to change either, really at this point), but for the purposes of illustration only (and because you asked for it )

This is setup to monitor a field, and when a word is typed in, find out if it is among groups of other predetermined words, then set a style. Since I did not have huge groups of words readily available, I chose to use some of the ones Lc already has

Code: Select all

# this script is in the field "txtEnter" script...
on textChanged
   checkWord   
end textChanged


on checkWord --theWord
   lock screen
   put word 2 of the selectedLine into tmpLine
   put field "txtEnter" into tmpField
   
   put word -1 of line tmpLine of me into theWord
   
   switch
      case theWord is among the words of the commandNames 
         set the textStyle of word  -1 of line tmpLine of me to "bold"
         break
      case theWord is among the words of the functionNames 
         set the textStyle of word  -1 of line tmpLine of me to "italic"
         break
      case theWord is among the words of the  propertyNames  
         set the textStyle of word  -1 of line tmpLine of me to "underline"
         break
      case theWord
         set the textStyle of word  -1 of line tmpLine of me to "plain"
         break
   end switch
   
   unlock screen

[jacque]

It works (almost) fine in LC 9.6.2 rc 2. The only issue is that the textstyle is not always reset after the handler sets the textstyle of a word. Without resetting, the textstyle remains for all subsequent characters until a different style is recognized and set.

To fix that, the last case of the switch statement just needs to be plain "default".

Code: Select all

on textChanged
  checkWord   
end textChanged


on checkWord --theWord
  lock screen
  put word 2 of the selectedLine into tmpLine
  put field "txtEnter" into tmpField
  
  put word -1 of line tmpLine of me into theWord
  
  switch
    case theWord is among the words of the commandNames 
      set the textStyle of word  -1 of line tmpLine of me to "bold"
      break
    case theWord is among the words of the functionNames 
      set the textStyle of word  -1 of line tmpLine of me to "italic"
      break
    case theWord is among the words of the  propertyNames  
      set the textStyle of word  -1 of line tmpLine of me to "underline"
      break
    default
      set the textStyle of word  -1 of line tmpLine of me to "plain"
      break
  end switch
  
  unlock screen
end checkWord

I'm not sure why you got the results you posted but maybe it had something to do with the switch construction. Or maybe that's just what you get for living in the dark ages. BTW, the word "space" is not a property, it's a constant, so that may be another problem with the version of LC you're using.

[bogs]

To fix that, the last case of the switch statement just needs to be plain "default".

Thanks, I couldn't figure that one out heh, and there wasn't anything about it in 6.x (which is what I am testing this in).

I really at some point need to go back and learn this language from the bottom up, as it sits, I probably only know enough to be dangerous (but really only to myself haha).

[johnf923]

First: the obligatory newbie alert!

In the original post Davidv gave an algorithm for combining two lists, with the second list updating the first. It went:

The code is thus a fairly simple step through of both lists, updating when the keys are equal. Logically, it goes in pseudocode:
if key(List1) < key(List2) then move to next List1 key
If key(List1) = key(List2) then update the List 2 line, move to next List2 key
else[ key(List1) > key(List2)] warn the user. -- This is an unlikely event, but when I ran it, I got a user warning on a key which was in both lists. The key in question was the string "NAN".

The algorithm works its way through the lists, at each step checking which list's current key was less than or equal to the other. The algorithm failed when it encountered the key "NAN", which is a valid stock market ticker but also a valid floating point number according to the IEEE standard.

My thought is that it's the algorithm that's flawed here because it assumes that
1. the lists are sorted by ascending order of key, and
2. The sort order of the lists is such as to match the sort order used by the > and < comparison operators.

The algorithm assumes that if key1 < key2 then key1 will appear earlier than key2 in the lists. But unless both the above conditions are true the algorithm is bound to fail, and I suspect that's what's happening. I can't prove it because the OP didn't specify the key sorting algorithm used. Still, if I'm right I'd expect the OP's "unlikely event" to actually be inevitable at some point.

Perhaps I could mention that NaN is unlikely to be the real problem because the same issue will arise if the OP ever decides to buy shares on the London market in the stock "888 Holdings Ordinary .5p" which has the ticker code 888 .

John