Digital Workshop

Hi Folks,
Need to intercept a mouseover in order for it not to go through all layered objects to the page level.

Scenario:
I have a mouseOver event that for now just displays the objects name, I have layered them ontop of each other and on mouseOver, all the objects display their name. How do I "escape" mouseover once it has reached a desired object, thus not displaying name of the object underneath?

Kind regards,

EOMC40

How do you determine what is the desired object? Also, you mention 'layers'... are you using SetLayer() at runtime, or just layers in the Editor?

by layer I mean a simple act of creating a button, add the following code to the mouseover

Debug.trace("\nName:" + this.GetName())

and then duplicating the object a couple of times and ensure that some are layed out ontop of others so the mouse event can be on a couple... The effect hence at runtime shows the debug trace showing for a bunch of lines at the same time.

(PS click on gif image animation)

I can think of a 'few' ways to approach this, depending on what your ultimate intentions and design are. If it is a game or a somewhat fast interactive educational pub -- that's one thing. If it is slower paced pub where the user actually hovers or pauses over the button, the script could be simpler.

Also helps to know how many of these objects or buttons there will be.

I'm going to go away and try something, with some assumptions, see what I can gen-up.

Using another development tool RunRev and their implementation of such a scenario would be that, on mouseOver of the topmost button, I would need to "pass" the mouseOver event so that I can access the underlying buttom's events, if I only want this to end here, in the code I just need to create an empty event which in effect acts as a trap

I am more on wanting to know how it is done in Opus, I encountered this just working through the drag-drop tests.

eomc,

By 'pass', I take it you mean 'not act on'? Or do you mean 'hand off'?

I was acting on the interpretation, or maybe an assumption, that you wanted the highest object in the Organizer (most in-front) to get the Mouse-over and the others to not respond to a MO (once this is implemented). Now I am confused as to what is trapping what.

Please take a look at the screenshot... which serves to illustrate the point.

Hi Lar_123,

In runrev, the "pass" idea is to say, I have dealt with this buttons mouseover (mouseUp in strict runrev) action and want anything beneath it if it has a mouseover event to also execute their action.
If however on this objects mouseover call I don't have a pass statement, then the statements stop here.


This will allow below objects to execute mouseover call



This will not






In Opus however, all objects below will automatically receive the mousover event and that's what I am struggling with.
The top most object hence in this "layered" situation should run its statements under the mouseover call and have a means of terminating any calls to objects below it.


Hence in your attachement, if a trapping mechanism is implemented it would mean, that whichever is the current object that has a mouseover, if it has not passed/allowed execution to proceed to an object that would be affected by mousever then the execution stops here, or proceed as the case may be.

Okay, thanks. I have a good idea now. I do not like the 'terminology' of the other app... but I have something partially working for Opus.

Will develop it and post soon.

Cheers.

eomc,

Okay, have something working. Should be easy to use and/or adapt.

Each object in the 'stacked set' calls a common function on MouseOver and on MouseExit.
As currently written, the stacked objects should be in a Frame and also be of same Object Type. (those are constraints we can probably get rid of in the future)

I hope and ask that if anyone finds a simpler way, or can improve on this initial Pub/function, please Post back... preferably .IMP files. I added some comments in the Script, listing a few other possible options/alternatives I can think of.

BTW, I was not so interested in the original problem as I was in practicing with OOP and arrays (it turns out that I started off in a more complex approach, then found that very little 'oop' was needed -- but I did pick up a bit of learning in the process).

[Lar EDIT:] I have removed the .IMP temporarily... I see a way to clean up the script -- back with it soon. ~9pm GMT?
[Lar EDIT:] well I tuned part of it, and broke another -- back at it later. Very close.



Cheers.

Okay, better now.
Script is, I think, cleaned, tuned, and working. (someone correct me if you find an error in the logic or operation).

Also, as before, am open to suggestions for improving and simplifying. Or just go ahead and modify it.

Cheers,
Larry

Hi Lar_123
Am not sure if I get the outcome you describe.

I am still seing the highlight border effect on the buttons underneath.


regardless to the choice at the top.

Looking at the priperties details of the button, I can see under the general tab, options "Stop mouse click passing through"
I think Opus should also implement "Stop mouse over passing through" because this is very basic and having to write code to effect this for multitude of objects is not very practicle...

EO,

I left the effects of the Rollover border there so you can tell what is going on in the 'demo'. Further, I built it in a way that you refer to what I call the 'hot object' by the variable 'currHiRank' rather than the original object name.

Maybe I misunderstood. I thought you were going to have the button control actions or animations of other objects.

If you were only concerned about the objects in the stack itself, and the displayed attributes (e.g., border), that is easy to solve. Use GetAppearance() to change it, and if need to use brute force, use RemoveFlare() or RemoveBorder() to override the 'mouseover' display properties.

eomc,

Some questions:
- will you have mix of object types or are they all the same type?
-- if they are all type "Button", do you need gradient background or other appearance characteristics?
- what other actions will be needed?
-- for example, if Button_3 is below Button_5 and its text does not normally show, do you need to hide Button_5?

Hi Lar
I think on the question 2 and 3, I think I would, again I am basing my implementation on how another application would allow me to do.
I should be a able to call-up functions from the scripts, that’s fine, and I have figured out how I can associate functions to objects, simply by giving the script the a derivative of its object name. With eval command I think I can almost get there but I find it somewhat convoluted, maybe just me forcing the other apps paradigm onto Opus. I have seen where you left the highlight and as suggested, I can use the built in functions to alter the look/feel.
Why am I here? The other app doesn't support rendered video which is the main item I need to be able to overlay objects on the scene. That's a big plus on Opus.
Will put together a working prototype and post it for your comment.
I have learnt loads from this discussion and believe you have as well found new things as a result. Thanking you for your input.

eomc40

EO,

Possibly true on both counts. The script I developed certainly makes it seem complicated or convoluted. Not sure what you are facing there. As for 'other paradigm', that's true in many sports --- racecar drivers do not usually switch from rally to formula 1 or vice versa.

I've modified the previous .IMP sample. I took out all of the 'flexibility' and variations. So just focused on handling only Buttons, and only 'Topmost object' in a stack.

What I discovered (i thInk) is that Button appearances are an interesting animal.

Specifically, to get this to work, I had to use only Button theme of 'Traditional'.
...let me qualify that.
I got it to work only with 'traditional'.
If it is possible to work with theme of 'Win XP' or 'Modern Smooth' --- I would have to work quite a bit more in the area of 'removing' and 'setting' appearances. That is just not of keen interest right now. (hence my earlier question on gradient bkgrnd).

Most of what I appreciate learning here is the manipulation of objects and how that handling objects that way really is bidirectional. A = obj B ; A.event = 'something' ; I can refer to B.event elsewhere. (maybe there's a better term for it).

I also got to practice with switch:case, which I like. Very clean.

For all of that and the discussion, I think the 'missed opportunity' here was in not looking further into RegisterEventHandler in conjunction with the ranking I did for the stack. At least REH would be useful for controlling other/external actions, but still would not offer any advantage for inherent border/button_bevel attributes.

New pub attached. Strict adherence to only one Button highlighted at a time.