[REQ] Control selection during browse mode

[Emily-Elizabeth]

Thanks for the hard work. I will check it out when I get home.

[Klaus]

Hi folks,

spread the word:
Mr. Boole is our friend and MOUSEMOVE comes with two parameters!

Code: Select all

on mouseUp
  set the selected of fld 1 to (the mouseLoc is within the rect of fld 1)
end mouseUp

on mouseMove x,y
   if abs(x - item 1 of the loc of the target) < 10 and abs(y - item 2 of the loc of the target) < 10
      ...

Best

Klaus

[FourthWorld]

So you can see the grey section, on the right, which has everything set with cantSelect and chooses the browse tool when moused over.
The white section, on the left, chooses the pointer tool when moused over.
The label needs to be selected, moved and resized, at the user's whim and right now that happens fine with the pointer tool (there are other issues that need to be resolved when using the pointer tool so I'd rather do the selecting, moving and resizing when the browse tool is in use). There are two modes to this - edit and browse, and the functionality only needs to happen in the edit mode.

Consider putting the tool panel into a group and setting the group object's cantSelect property to true.

The cantSelect property was implemented in 1999 at my request as a solution for this sort of application design.

[dunbarx]

Klaus.

Always much more compact.

I had the idea that using the "long" way would be more instructive, comparing the similar item numbers between the two. I would not have done that if I were talking to you.

Craig

[Klaus]

I admit this is just my pure lazyness!

[dunbarx]

We are both likely too lazy to even speak to each other.

[Emily-Elizabeth]

Consider putting the tool panel into a group and setting the group object's cantSelect property to true.

Yeah, that makes sense (too bad I did it the long way), but I'll add it to the group now so I can add new items and have them automatically have that property set.

[Emily-Elizabeth]

Here is a sample stack. You can move the field, and again only the bottomRight works until you bless the method.

Thank you. It works well except that when there are two controls on the card, trying to move one causes the two controls to join at the loc of the control you are trying to move and moves them both.

[stam]

It’s also possible to move the mouse so quickly that the cursor ends up in the middle of the rect and you end up moving the rect instead of deforming it.

[Klaus]

We are both likely too lazy to even speak to each other.

Well, I wouldn't go THAT far...

[dunbarx]

Stam.

It’s also possible to move the mouse so quickly that the cursor ends up in the middle of the rect and you end up moving the rect instead of deforming it.

That has always been a weakness of that sort of kludge.

Emily.

i see you do not know the simple answer to that. Here is a modified stack. The only difference is that all instances of "fld 1" have been changed to "the target".

But do you know why that works?

Craig

noPointerTool.livecode.zip

(1.46 KiB) Downloaded 65 times

[dunbarx]

@Stam.

I changed the differences between the botRight and the mouseLoc to 30, and one really has to work to drop the resizing acton. That value may overlap the coordinates of the loc, depending on how large the actual field is, but the mouseMove handler deals with moving the control first, so it does not seem to matter. I think this is robust enough for anyone. I am not sure I currently have another way of using the browse tool the way Emily wants it.

@Emily.

Are you able to add the ability to work in all four corners? You should be able to see what to do by examining the code in the case statement for Bottom Right. The new stack also supports the topLeft, to get you started. If not, I can do it for you, but then you are not learning LC as fast as you need to.

Craig

noPointerTool.livecode.zip

(1.68 KiB) Downloaded 64 times

[dunbarx]

Emily.

I apologize for that last. You will learn as fast as you can, and want to. It was unfair of me to say that.

Anyway, may I assume that you no longer have any reason to select a control? The recent test stacks do not need to. I understand why you initially thought it was the correct way to proceed, but it is an unnecessary extra step, in my opinion.

Craig

[Emily-Elizabeth]

Anyway, may I assume that you no longer have any reason to select a control?

the end user still needs to select the control so they can rename it/change the label text.

[dunbarx]

Emily.

the end user still needs to select the control so they can rename it/change the label text.

Rename it? What does that mean? Change the field text I get. But why are you using label field?

In any case, neither of those require that the control be selected. Or am I missing something?

Can you do these new things?

You really must try to lay out your ideas, as best you can, as early as you can. I do not mean to sound severe, after all, I have nothing but fun doing this sort of thing. But as your projects become more complex, you must plan them better, and create what is known as a functional requirement more completely. It saves time.

Keep at it...

Craig