Weird image control behavior in edit mode-- Is this a bug?

[fgr33n]

Hi all,

It appears that if you have a mouseUp handler in the stack script, selecting an image control in edit mode will execute the mouseUp. All the other controls seem to behave as expected-- they get the selection outline. But the image gets the selection outline, and then the mouseUp executes.

I tried this in 7.0.4 and 7.0.6 commercial and 7.0.6 and 8.0 community. All did the same thing.

Could someone try this test stack to see if you get the same thing before I file a bug report on it?

Thanks in advance! Fred

[FourthWorld]

The Dictionary entry for the mouseUp message (and some other mouse-related messages) is currently incomplete. In response to your post I just filed a bug report with alternative wording that more accurately reflects how the mouseUp message is handled:
http://quality.runrev.com/show_bug.cgi?id=15583

[fgr33n]

Hi Richard, I downloaded the test you made, and was getting different behavior with it than with my stack.

After looking at your stack, I think the problem I was seeing is with the mouseRelease command, rather than mouseUp. In my project I was call mouseUp from within the mouseRelease, so it could have been either.

I put a mouseRelease handler in your sample stack, and every time I select an image with the edit pointer the mouseRelease is firing. Seems to me that the IDE should also be trapping mouseRelease on images while editing?

Maybe you could try this sample and see what you think?

[FourthWorld]

In the notes I included in the report I mentioned the difference between IDE and standalones with regard to mouse messages. Unless you made a standalone from the sample stack I included with the report, not all of the pointer message will be received by objects in it, for the reasons I described in my proposed Dictionary addition.

Perhaps the text I included there just wasn't clear enough, which may be worth your adding a comment there to make sure it's complete and clear.

[fgr33n]

Hi Richard, Sorry if I'm being dense, but the problem I'm trying to describe doesn't involve image transparency areas, the dictionary entry or stand-alones.

When I select an image in the IDE, with the editing pointer tool, mouse events are still getting executed.

In bug report terms:

ACTION: click an image control on the card while IN THE IDE with the EDITING POINTER TOOL.

EXPECTED RESULT:
1) a selection box appears around the image control, allowing for editing, setting properties, ect.

ACTUAL RESULT:
(If navigation code exists in a mouseRelease handler on the stack script)
1) a selection box briefly appears around the image control.
2) the IDE displays a different card.

Since I have some navigation code in a mouseRelease handler in the stack script, selecting and editing images on cards is currently impossible. The only option is to remember to select the image in the project browser. Selecting it on the card will result in navigation rather than the opportunity to edit.

I still can't tell if you were able to reproduce the issue I'm seeing, but your post about image transparency areas, the card underneath getting messages, the dictionary entry for images, and stand-alones makes me think we aren't even talking about the same issue.

If we are talking about the same issue, they my addition to the dictionary would be,

The edit pointer tool traps mouse events within the IDE to allow editing of most controls. The exception is the image control. When clicked in the IDE with the edit pointer tool, the mouseRelease message will not be trapped, causing navigation to run if present (in the mouseRelease handler on the stack script). If you want to select an image control for editing you MUST DO IT IN THE PROJECT BROWSER, as trying to select it directly on the card will result in navigation away from the card.

[FourthWorld]

The edit pointer tool traps mouse events within the IDE to allow editing of most controls. The exception is the image control. When clicked in the IDE with the edit pointer tool, the mouseRelease message will not be trapped, causing navigation to run if present (in the mouseRelease handler on the stack script). If you want to select an image control for editing you MUST DO IT IN THE PROJECT BROWSER, as trying to select it directly on the card will result in navigation away from the card.

Yes, the image object is an exception with regard to the IDE's handling of it with mouse-related messages.

While the Project Browser is one solution, if you want the messages triggered only while the browse tool is active you can check for that in your script:

Code: Select all

on mouseRelease
   if the tool is "browse tool" then
       DoBrowseToolOnlyStuff
   end if
end mouseRelease

[fgr33n]

Hi Richard, Clicking to edit is so ingrained that I keep forgetting, and clicking images on the card to edit them. By adding the "tool" check it now stays on the same card. This definitely will help with my sanity going forward. Thanks again.