Buttons on Frames - a new bug?

[fh1805]

I stumbled across this behaviour (which I am convinced is a bug) whilst preparing a Demonstration/Tutorial session about Audacity sound editor. The mini-project attached below demonstrates this unusual behaviour. You will need to unzip the contents into a folder because there are two text files that are the targets of the two buttons. There is no sound associated with this PTE project.

As you play with it you will need to study the structure of the objects in the Objects List panel of the Objects and Animation window. You will also need to keep an eye on the slide number that is displayed at the top of the screen.

To try and summarize what I have found:

If the buttons are placed directly on the Background (as child objects) everything works as it should.

If each button is placed in its own frame, then only the button in the first frame behaves correctly, the other button simply advances to the next slide

The only difference between slides 5 and 7 is that the order of the Frames has been changed

Note that slides 1 and 2 are PTE-generated Blanks (PTE doesn't seem to add the Slide Number text comment to these (another bug?)), the other blank slides are BlackSlide JPEG files.

Although not included in this project, if all buttons are placed in a single Frame everything behaves as it should. I have not tried with more than two Frames but I suspect that only the first will work correctly no matter how many there are. I also suspect everything will be OK if the buttons are placed as totally independent objects, but I haven't tried this either.

regards,

Peter

ButtonBug.zip

[xahu34]

For the frames: Try the option "Transparent to selection".

Regards,

Xaver

[Guest Yachtsman1]

Hi Peter

Can't give any assistance on this problem because the sample is in a later version of PTE to mine & it only operates in the mini player. However, we seem to have had a conversation in the past about the logicallity of the mouse buttons, surely "left to go forward & right to go backwards is not logical.

Yachtsman1.

[xahu34]

... However, we seem to have had a conversation in the past about the logicallity of the mouse buttons, surely "left to go forward & right to go backwards is not logical.

...

This is an odd logic.

Peter has made a definition for the mouse action, so what he did it is logical

Anyway, thank you for another helpful remark.

Regards,

Xaver

[Guest Yachtsman1]

Are the arrow keys on your keypad different in Germany?

Yachtsman1

[xahu34]

Are the arrow keys on your keypad different in Germany?

Yachtsman1

I was talking about logic. In Britain, people drive on the left side of the road. Nevertheless, I would not call them illogical

Regards,

Xaver

[Guest Yachtsman1]

I was talking about logic. In Britain, people drive on the left side of the road. Nevertheless, I would not call them illogical

Regards,

Xaver

[/quote

But they don't turn their wheel left to go right.

Yachtsman1.

[fh1805]

Hi Peter

Can't give any assistance on this problem because the sample is in a later version of PTE to mine & it only operates in the mini player. However, we seem to have had a conversation in the past about the logicallity of the mouse buttons, surely "left to go forward & right to go backwards is not logical.

Yachtsman1.

It's the old Powerpoint Standard!

[fh1805]

For the frames: Try the option "Transparent to selection".

Regards,

Xaver

Xaver,

If your suggestion was to work (and I haven't tried it) it would suggest that one Frame already is transparent to selection but the other isn't. I'm not looking for another workaround. I'd simply like to understand why the behaviour is as it is.

regards,

Peter

[fh1805]

Can't give any assistance on this problem because the sample is in a later version of PTE to mine & it only operates in the mini player.

Eric,

Perhaps it is time to consider upgrading? After all, you've just bought yourself a new super-fast laptop that has all the "ooommph" you need to drive PTE v7.

Peter

[xahu34]

Child objects sit on top of their parent object. In slide 7 of your example we have the order: Button2 (on top) > Frame2 > Button1 > Frame1. Thus, Button1 is covered by Frame2, while Button2 is "free" (as long as the text comment will not be placed at the position of Button2).

I do not see a bug

Regards,

Xaver

[fh1805]

Xaver,

Excellent analysis on your part.

For the frames: Try the option "Transparent to selection".

That gets the desired result!

I do not see a bug

Neither do I, now!

However, I think this raises a new issue. The PTE Frame object is intended to be visually transparent. Should it, therefore, have a default value of "Transparent to selection" = ticked? Then, the only way to select it would be via its name in the Object List in the "Objects and Animation" window. Any click within the area of the Frame would then automatically pass through to the lower layer object(s). And whilst we are discussing the attributes of the Frame object, its Opacity should be "locked" at 0%, shouldn't it? If we want a visible Frame we have the Rectangle object: which is only a Frame at 100% Opacity (or is it the Frame which is a Rectangle at 0%? )

regards,

Peter

[Guest Yachtsman1]

Eric,

Perhaps it is time to consider upgrading? After all, you've just bought yourself a new super-fast laptop that has all the "ooommph" you need to drive PTE v7.

Peter

Hi Peter

The reason I haven't up-graded, I am happy the version I am using will do all & much more than I can get it to do. I was waiting until the sound editor bettered what I use, looks like it will be a long wait. When something comes along that really floats my boat, I may.

Regards Eric

Yachtsman1

[Igor]

Peter,

Thanks for raising the interesting problem!

A Frame object can be used as a rectangle area to simulate a graphical button on an Image object. I remember that Lin Evans used this technique in his works.

Can I suggest the following change. Frame (with zero opacity) will be automatically transparent for mouse clicks if it doesn't have assigned "Action" (in the Common tab). It should solve this logical issue.

[fh1805]

That would be a very suitable solution. The behaviour then would be:

- User creates a Frame. The Action is None by default therefore "Transparent to selection" is ticked automatically by PTE

- User changes the Action to some value other than None, PTE automatically unticks "Transparent to selection"

- User changes their mind and sets Action back to None, PTE ticks the box automatically

regards,

Peter

[xahu34]

... And whilst we are discussing the attributes of the Frame object, its Opacity should be "locked" at 0%, shouldn't it? If we want a visible Frame we have the Rectangle object ...

The new concept (as proposed by Igor) would be OK for me. Locking the opacity at the value of 0 would not be what I would like. I often use frames, and during the construction process, I temporarily make them semi-transparent. In this case I would not like to change the objects. For me, having both object types (frames and rectangle) is a kind of redundancy. In principle, we only need one of them.

Regards,

Xaver