pick and drop in model world

[r...@amalasoft.com]

Hi All

I decided to see what I could do about using pick-and-drop in the context of an EV_MODEL_WORLD.

While I can set the pebble to a model in the world, I can never get a drop event from within the world.

I tried giving the world and its enclosing/associated world_cell, and even the world_cell's drawing area an drop action, but it never fires.

Taking the example from here:    https://www.eiffel.org/doc/solutions/EiffelVision_Pick_and_Drop

I was able to duplicate its behavior just fine, but using the button widgets in the example.

I can even drop the model-as-pebble onto the button from the example, but get no events when dropping in the model world (and the deny cursor is present there too, of course).

Suggestions welcome.

Thanks

[Larry Rix]

Is it because a higher level class is swallowing the event? For example--model-world is getting the drop-event and doing nothing with it instead of passing it down to items it contains?

Is it possible that an even higher level class than model-world is swallowing the event? Perhaps even a Windows-level OS object. I've encountered this behaviour before and it has been just such a problem and the solution has been to teach the higher-level object to examine the event and pass-it-down to lower level contained objects.

[r...@amalasoft.com]

Hi Larry

I added drop event handlers to every class I could find (well, almost).

Model world exists within a model world cell, model world cell has a drawing area.  They never fired.  I even tried an individual model and, while the picked just fine, they too would not respond to the a drop event.

I even tried dropping a picked model onto a button (makes no sense, I know, but this was investigation) and, lo and behold, the drop event fired.

I added drop event handlers to all of the aforementioned elements at the same time, hoping to track which one caught the event, but none did.

There remains, as you suggest, the very distinct possibility of a lower-level _event_ (pointer button actions) masking the higher-level event (drop) and I will jump on that right now and let you know.

Thanks

R

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/a9d8fc81-df3c-4aa8-95b3-0062e0f3daaan%40googlegroups.com.

[Larry Rix]

As I recall, we encountered this with scroll-bars where we wanted a typical scroll-wheel behaviour, but it turned out that the wheel event was not getting passed to the bar, but was being intercepted early and silently swallowed higher up. Eiffel Software (Manu, specifically as I recall) handled this for us. I think that code is now in Eiffel Vision2. Perhaps what you are hitting is a similar correction needing to be applied.

[r...@amalasoft.com]

Hi Larry

My initial roadblock could be attributed, it seems, to a hardware problem (the nut behind the keyboard).

With a bit more instrumentation, chasing the hungry hungry hippos of event land, I did find some event eating, BUT, I found also that model world was more cooperative than my previous attempts had indicated.

I had, already, added the pick events to the individual models, but had unwittingly masked the drop events for the model world by giving other classes the right to catch (and eat) the events.  There's a moral here.  Sometimes setting too many traps will allow the intended prey to escape.  And you'd think, after the one or two years I've been at this programming stuff, that I'd have that concept well burned into my brain.

I have more investigation to do, but I'm no longer blocked by event voodoo (or rhymes with voodoo).

Thanks again,

R

-------- Original Message --------
Subject: Re: [eiffel-users] Re: pick and drop in model world
From: Larry Rix <lar...@moonshotsoftware.com>
Date: Sat, November 28, 2020 8:38 am
To: Eiffel Users <eiffel...@googlegroups.com>

As I recall, we encountered this with scroll-bars where we wanted a typical scroll-wheel behaviour, but it turned out that the wheel event was not getting passed to the bar, but was being intercepted early and silently swallowed higher up. Eiffel Software (Manu, specifically as I recall) handled this for us. I think that code is now in Eiffel Vision2. Perhaps what you are hitting is a similar correction needing to be applied.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/826178fa-cf14-41e2-a885-150a0507b24bn%40googlegroups.com.

[r...@amalasoft.com]

Hi Larry (et al)

As it happens, model worlds behave correctly w/r/t pick-and-drop (even if some programmers don't).  Just follow the directions, and don't try to overthink it too much.  Just sayin'.

The working setup is very simple in the end.

For each model in the model world, call set_pebble with the model itself as argument.

  my_model.set_pebble (my_model)

That will enable a reference to that model to be including in the drop event, when a drop attempt is executed.

To enable the model world to catch the drop event, add an agent to its drop actions.

  <world.>drop_actions.extend (agent on_model_drop)

The signature for the drop agent, is

   on_model_drop (m: EV_MODEL)

Because model worlds can handle quite a few different event-based interactions, it might seem silly to use pick-and-drop.  Pick-and-drop, from an ergonomic perspective, is a big step up from drag-and-drop, but the latter is what's familiar to most users.

The good news is that you can have both in a model world (and some other contexts).

The familiar drag-and-drop will still be there but, given the option, I suspect pick-and-drop would become the preferred mechanism.

If you wish to drop that model onto some other element, an inspection dialog, for example, then P&D is essential, and pretty cool too.  While it might be possible to track mouse leave/enter pairs and pointer down/up pairs in concert, to support a kind of drag across widgets, it's an enormous pain and gets very complex, very quickly.  P&D is an elegant (and dramatically simpler) option.

Thanks

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20201128071010.cf48dd763fcaf5d42559c6c92f6fc53b.16ccb1d4e2.wbe%40email25.godaddy.com.