please give me just a clue.....

[chris25]

Hi Ok this is an example of 'absence of real clarity'. I first looked in the dictionary by typing in: two words " is not". common sense playing here you know. The I see 9 operators. Based on a few minutes of reading I choose either "is not a" OR "is not an". This is because there is clear INTEGERS involved whereas the rest default to words text strings. Again, my logic of deduction. So it is with some surprise that I see the answer to my problem was:

if the text of me is not among the items of "360,300,240,180" then (is not among is the key operator here I am referring to)

In other words in the dictionary there is absolutely no indication that this could even be remotely the right operator in this instance. So can you explain Mark please.

Kindest regards
chris

[Mark]

Hi Chris,

If you search the dictionary for "among", you will see all the information you need. The search routine of the dictionary is imperfect and it takes some time to figure out how to do a search. Yes, it is strange: you'll easily find something if you know what you're looking for, but most people who use the dictionary do so because they are trying to find out what they're looking for. Kind of a catch 22.

Also, the dictionary tells you how to use individual commands, functions, properties and messages, but it doesn't tell you how to write a programme. I'd recommend reading tutorials and books for that.

What the dictionary doesn't tell you is that you can use "among" with any kind of container reference that evaluates to a list of items, words, lines, characters, bytes or keys and that you can specify items using the itemDelimiter, which is comma by default.

Code: Select all

...if x is among the lines of fld 1 then...
...y is among the keys of myArray...
...numToChar(14) is among the chars of url ("binfile:path/to/file")...
...numToChar(14) is among the bytes of url ("binfile:path/to/file")...
// etc...

Kind regards,

Mark

[chris25]

This code only ever works when you click on anything outside of the application stack itself. I will work on it though. I have changes things from what you wrote only to see if anything was getting in the way

on closefield
  if the text of me is not among the items of "360,300,240,180" then
    answer "360, 300, 240 or 180"
    // the next line is optional
    // don't use it if it causes problems
    --send "select the text of me" to me in 0 millisecs
  end if
end closefield

[Mark]

Hi Chris,

Do you have an object that covers your entire stack window? That explains why a click doesn't close the field. You can move the contents of the closeField handler to card level and call the new handler from both the closeField handler (just to be sure) and a mouseUp handler in e.g a card-wide graphic or whatever object you have there.

Kind regards,

Mark

[chris25]

Just solved it: with the following idea I had

on mouseleave
  if the text of me is not among the items of "360,300,240,180" then
    answer error "360, 300, 240 or 180"
  end if
end mouseleave



No, there is only a background image but that is on layer 1 number 1. The group in question sits above everything. And I do not really understand this:
====move the contents of the closeField handler to card level ===(OK this I understand)===
==== and call the new handler from both the closeField handler (just to be sure) and a mouseUp handler in e.g a card-wide graphic or whatever object you have there.===== (this I don't really get at all)

[Mark]

Hi,

MouseLeave won't do it.

The background image is what causes the problem. It can't get focus and thus focus stays with the field, preventing the closeField message from being fired.

If you add a mouseUp handler to the image control, this mouseUp handler can call new handler at card level. I already explained this when I wrote the example with the clearAllFieldsAndVars handler.

You can call the clearAllFieldsAndVars handler from both the mouseUp handler in the image script and the closeField handler in the field script. This way, you work around the focus problem. Additionally, you can call the clearAllFieldsAndVars handler from the mouseUp handlers in the radio buttons. This way, every time when the user changes something, you check if the number is correct.

If you don't understand something, please be very specific about what you don't understand.

Kind regards,

Mark

[chris25]

Hi Mark, but it does It does work and very well I tested it at least 10 times under different conditions

[chris25]

I do not understand what you mean when you keep using the expression: ...you can call... what does this mean in Practical terms?

If I write a handler in card 1 then card 2 can call it? How? I only understand tis in terms of a variable being called, not a a handler

[Mark]

Hi,

Calling a handler just means that you include a statement that executes a handler. In

Code: Select all

on mouseUp
  foo
end mouseUp

the handler foo is called, be it in the card, the stack or in some library. "Call" is almost synonymous with "put it on a line in your script"

And yes, your mouseLeave handler executes if you move the mouse. However, if you don't use a mouse but instead use the tab key, it won't execute. Therefore, the mouseLeave handler is not a solution to this problem.

Kind regards,

Mark

[chris25]

But this statement

=====The background image is what causes the problem. It can't get focus and thus focus stays with the field, preventing the closeField message from being fired======

begs the question then Why? Does this always happen whenever one uses a background images? I doubt it? I do not see how I caused it?

chris

[dunbarx]

Chris.

The message hierarchy is a fixed progression of object layers, whereby a message may start at a lower level and (possibly) move up to a higher level.

You work at a low level every time you write "mouseUp" in a button and let that message (mouseUp) be dealt with in that button. But the message is generated when you click on the button, and it makes no difference if there is a handler for it in the button or not. Now let's say you put a "mouseUp" handler in the card script. \If you click on a button with no handler it will let that message pass, and it will be caught by the card. In this way you can have several buttons that share that handlers functionality. By using the "target" function, that handler can even know which of its "children" generated the message, and possibly act accordingly.

When Mark says to "call" another handler, he means that one handler invokes another, in what used to be called a "subroutine", either by simply stating the call, again in a button:

Code: Select all

on mouseUp
beep 3
doOtherTask
end mouseUp

This would pass up the hierarchy, and if there was a "doOtherTask" handler in the card script, it would execute as well.

Now, you can send that message to other places than the natural order, even down a level, by using the "send" or "dispatch" commands. He is working with you on the layers of your objects, and this may be an issue for you. He is suggesting that moving a handler to a different level may allow messages a clearer path, or a more universal one.

This takes a bit of practice to get the hang of, but it is one of the fundamental cornerstones of the xTalk structure, and contains enormous power. A very new user often writes many identical handlers in, say, many buttons. These all could be managed perhaps by a single handler in the stack script. And if a change was required, only one handler needs to be dealt with. Imagine trying to go through all those buttons and make changes.

Craig

[Mark]

Hi Chris,

Yes, that is what always happens if you use images. They aren't necessarily background images. They're just images and they can't get focus. Fields and buttons have a property that's called traversalOn. This property determines if those objects can get focus. I.e. when you use your keyboard, something happens with those objects. Images have this property too, but they don't seem to respond to keyboard input.

I agree that this is a little strange. If buttons can have focus, I'd expect images to be able to have focus too, but they aren't. Since an image can't have focus, a field won't lose focus when you click on an image.

Sorry

Mark

[FourthWorld]

While an image can't be focused per se (per the HIGs), you can add something like this to at least deselect fields:

Code: Select all

on mouseDown
   select empty
end mouseDown

If you want to simulate focus you could add to that to turn on the image's showBorder property, using a borderColor that matches the focusColor of other controls.

[chris25]

Craig: I thought that I understood the message hierarchy until I just read what you wrote. Now some other stuff comes together and it becomes clearer as to what is happening. I never saw this 'Power' you referred to until you explained it, I saw the message hierarchy as a sort of prioritising flow, while it is that I had not appreciated how one could manipulate this to a great advantage, it explains a lot actually. Thankyou. I see that images and graphics are on the same level as buttons and fields unless they are in a background group, which mine is of course.

Mark. Wonderful, now this really does clear so much confusion up now that you said this. Thankyou.

Richard: Do you mean adding the mouseDown handler to a text field with a mouseUp handler in it as well? I can't follow this, I do not want to have a focus on any image when you said "while an image can't be focused…" the inverse of this makes me think that you think that I want to focus on an image. Sorry for the confusion, but can not follow what you mean here .

Kind regards
chris

[Mark]

Hi Chris,

Just forget about that mouseDown or mouseUp handler in an image for now. It it possible to remove the focus from the field that way, but it still won't fire the closeField message, so that isn't useful in any way. Of course, there is a way to work around this by sending the closeField message from the mouseUp script in the image to the field, but that only makes things more complicated that they already are. You can do that later, say in a few weeks, when you are more experienced with LiveCode.

Kind regards,

Mark