LiveCode Forums.

@ Herman, beautiful, concise, simple !

@ raugert, see? Now there is code I'd call gold of the realm

raugert wrote: Fri Mar 09, 2018 7:42 am The issue of switching back and forth wasn't really your code. Your code works good for getting the button parameters into a field, but then I can no longer move/size object. So I was trying to add some code to it.

Ah, I get it. Yah, what I wrote was only to obtain the objectives I saw in the thread, change to pointer/browse tools, put the info into the field.

I don't think your asking too much, and I'm sure it has been done before. The way I usually go is, if your code works, but you think it can be done better, go with it and stick a comment inside the block to remind yourself to revisit it.

As your experience grows, you can revise it with better methods you might think up. Insights come at peculiar times (for me anyway), not always when I'm thinking about a particular problem, and often when I think I have stopped thinking about it completely. Not sure why it happens that way, but after near 30 years of it I stopped questioning it at this point heh.

Anyway, good luck with your project

[-hh] wrote: Fri Mar 09, 2018 6:40 am If you really want to work with the pointer tool then you could simply make a check button "EDIT" with the following script.

Code: Select all

on mouseLeave
   if the hilite of me then choose pointer tool
   else choose browse tool
end mouseLeave

on mouseEnter
   choose browse tool
end mouseEnter

Check the button if you wish to have the pointer tool and do what you want with several objects. When done uncheck the button and you are back in browse mode.

If you set the cantSelect of the checkbox it'll always remain in browse mode, no code needed.

FourthWorld wrote: Fri Mar 09, 2018 2:39 pm If you set the cantSelect of the checkbox it'll always remain in browse mode, no code needed.

Well, while that is true (ie. you can't select it so you can't theoretically change it), it *can* produce some funny results, especially if your changing pointer modes. In this case, simply setting 'cantSelect' prevents the checkbox from being changed (size, etc), but not reported (previous code), or apparently selection ringed. -hh's code would prevent this from happening, and for the same number of code lines.

bogs wrote: Fri Mar 09, 2018 3:01 pm In this case, simply setting 'cantSelect' prevents the checkbox from being changed (size, etc), but not reported (previous code), or apparently selection ringed.

Perhaps I had misunderstood, but I had thought preventing the checkbox that governs tool mode from being selectable was the point.

I co-designed the cantSelect property with the then-engine-developer, Scott Raney, back around '99, as a workaround for having only global tool modes. Some other xTalks like SuperCard and Gain use tool modes local to a specified window, without affecting the tool modes of other windows. With the flexibility of LC's groups, a better fit for us would be to have tool modes specific to groups - see: http://quality.livecode.com/show_bug.cgi?id=623

But that would have been a bit of work to implement, so we worked out cantSelect as a less graceful way of achieving a similar result, to allow the creation of custom drawing environments in which content and controls use different modes. In this context "content" refers to the objects the user manipulates with the pointer tool, and "controls" refers to the buttons, menus, and other options used to change modes, set properties, etc.

Consider a simple drawing program, with a column of tools on the left and a canvas on the right. If you set the cantSelect of everything in the tools region, when in pointer tool mode only the objects in the canvas can be manipulated with the pointer tool.

With the example you posted, if the role of the "check" button is to govern the tool mode, you would want that to operate as though it's permanently in browse mode, much like the tool buttons and other controls in a drawing app.

If by "selection ringed" you mean dragging around the object, that would be a bug. Once a control's cantSelect is true it's in browse mode, regardless of whatever global tool mode may be in effect. If you see behavior different from that please post a sample stack, and note which version of LC you're using. In v9dp11 cantSelect works as expected here.

FourthWorld wrote: Fri Mar 09, 2018 3:49 pm Perhaps I had misunderstood, but I had thought preventing the checkbox that governs tool mode from being selectable was the point.

Well, it is equally possible I am over-thinking the problem, or misunderstanding it myself, don't feel all alone, come on in and join the confusion that is my mind (**Warning, if you can't get back out, I can't help you).

My conception of the original problem in this thread was -

• Set pointer mode so that the user can move and size a button (I possibly mistakenly assume this means you desire to have the selection ring showing the points you can drag to modify the object, as well as showing which object(s) are currently selected)
• When a user then clicks on a button, it would display its location, id, etc., into individual fields...

Now, while setting the cantSelect of the checkbox *does* leave it un-editable, i.e. in 'browse mode', in the context of the previous code, it still shows the selection ring and reports its position in the field. My thoughts were that this may lead to user confusion, since cantSelect only stops some of the mouseDown messages, but not all of them. The check box shows it is selected, but isn't resizeable, etc.

Too offset this, you could add more code, but at that point your writing code, what I understood your point of using cantSelect to avoid having to do, and going nearer to -hh's solution. Even there, though, the report is made to the field, and the selection ring is temporarily around the check box.

I am sure you know I don't use dp releases and I don't recommend them to someone trying to figure out how to do something either. Why add possible problems not of your making to something if you don't have to? I realize our friend here is using it, though, and it is a valid point that I did no testing using it as a release.

However, in 8.1.6, the behavior is still the same Like I said, though, I may be over thinking it or completely off target, but if I set 'cantSelect' on something, then I expect it to appear as if it isn't in pointer mode, not as if it is selected (the selection ring), or report its position in the field.

I'll see your drawing program with a readily available counter, can you imaging how confused we might be if you cicked on a button in the tools palette of the IDE, and it looked as if you had selected it on your main stack? It is desireable to have the button hilite for sure, but not to look like you have it ready for modification.

Despite that, though, I completely agree with the way you guys all went with it back in the day, I use it frequently in other things

** Sort of an interesting aside, in IDEs v6.5 to 7.x i had no problem running this test and getting back to the IDE by hitting 'Restore Development', but in 8.1.6 I actually had to force quit it

If you get selection handles by clicking on an object that has its cantSelect set, that would be a bug.

Unfortunately, I'm unable to reproduce that. Do you have a recipe for a specific version?

Hmm, maybe I'm doing something wrong then. As for a recipe, when I set the can'tSelect on the check box to test what you had put, I opened the messagebox, typed in 'set the cantSelect of button "Check" to true', then suspended the IDE and ran the program.

The button on the bottom right is to set you back to browse mode through code, and doesn't get selected under any circumstances. As far as I can tell, the checkbox shouldn't get selected either, as when I type 'put the cantSelect of button "Check"' into the message box, it comes back 'true'.

This is a LMDE2 box running Jessie x64.

Stack was made in 6.5.2, but I opened it through the versions up to 8.1.6. Now mind you, the code from above is still active in the stack, but I don't think that should be able to affect something with cantSelect set. Maybe I'm wrong.

Ah, i see. You're not clicking the control, but setting the selected property via programming. The result you see should happen with all objects when the browse tool is active, whether globally or just on one object.

Much in LiveCode is like that: it's easy to do obvious things for end-users, yet usually also does not prohibit non-obvious things that can be scripted by developers.

Ok, that one lost me. You mean to tell me you can't set the cantSelect through the messagebox?

Or are you talking about this part of the code - Then this is what I was talking about up there, if you set the control to 'cantSelect', then that part of the code should never show a selection ring around the checkbox, Just like if you for instance, put a picture background in your stack as a skin and set it to cantSelect, it stops becoming selectable in the IDE.

Or, like I said, my understanding of 'cantSelect' is not functionally correct, which is certainly what I'm thinking now

*Edit - I think I see now, to overcome the other code, you mean you have to throw an empty mouseUp/Down message into the control to intercept those messages, that it?

I meant the opposite: as you've seen, any property, including cantSelect, can be set from the Message Box. You can also set the selected property from the Message Box.

CantSelect only governs whether an object is selectable by clicking with the pointer tool. It does not prevent you from setting the selected property via script.

Gotcha (I think)

So, if I have set 'cantSelect', but I write code that selects stuff, in the objects script I need to put an empty handler to catch the message that would otherwise go to that code to prevent the selection from showing around that object (in other words, the edit from the last post).

Whose on first? Not this guy

Presumably if you're writing the code, you'd check the cantSelect property and omit those controls from your selection.

The cantSelect property only affects manual selection by users. Scripted selections still work. If they didn't, the IDE, property inspectors, and app/project browsers couldn't function.

Got it now, thanks for setting me straight all.