Strategies for popups (in terms of touch/click propagation)?

Post reply
0 favourites
  • 11 posts
From the Asset Store
Fidget Pop Us Pop It Anti-Stress
$17 USD
Relax and relieve stress by popping bubbles in Fidget Anti- Stress Releaser!
TheArtfulMaestro's avatar
TheArtfulMaestro

  • For some reason, contrary to multiple other frameworks, Construct has always enforced touch/click propagation to lower layers, meaning clicking something will also click everything below it.

    This is a hassle with popup messages, settings windows and basically anything that appears over the play area.

    I already suggested adding a "Stop Touch" behaviour a couple of times so that the clicked object doesn't let through the event any further, but since there's no such a thing it requires control variables or switching groups on and off and other workarounds.

    Unless 1. There's some sort of a nice feature I don't know about. 2. Someone has a brilliant idea/workaround/hack on how to handle it?

  • i use a boolean, "popup".

    when set only buttons in popup works. other buttons only work with boolaen not set.

  • Global, and instance variables, everywhere.

  • I keep all my touchable objects in a family, then on touch "Pick top instance" filters out all instances below the top one.

    all of the touchable objects also have an instance variable saying which function to call when they are touched. So one place handles all the touch / multi-touch logic, then when it is determined what was touched it branches to the function that handles what happens from there.

    if I want a button or group of buttons to be modal (so that nothing else on the screen can be touched), I use an invisible object called ButtonShield that is part of the family and expands to cover whatever area I want, but has a blank function variable and it goes just under the active buttons in z-order. (since I always use pick top instance, this blocks any other objects below the shield)

    there are a bunch of other tricks to make a user friendly, proper multi-touch, intuitive UI. It is harder than you would think, but C3 gives you all the tools to make it work exactly as you want.

  • AllanR, thanks, very clever. Actually I love how much control this solution gives you. It also avoids the clutter of variables and irrelevant event groups just to prevent accidental clicks.

    I was thinking of simplifying it a bit by retrieving the name of the Sprite for identification (vs having a variable), but I think Ashley once explained how this is not possible for security reasons.

    I will still say that it would be nice to have some sort of a 'stop touch' behavior or the possibility of adding multiple Touch objects (so that different things are handled by different Touch - then enable/disable accordingly). Instant solution.

    Unless these are also problematic; e.g. having something to do with C3's renderer working bottom to top.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • if you are using a family, you can identify the sprite name with family.ObjectTypeName

    however, I think the issue is minification. Picking a sprite by .ObjectTypeName will work, but if you are comparing to a literal string, that might not work after minification... haven't tested it.

    I like the fact that C3 lets me decide how touches work / which instance a touch applies to. I like buttons to only execute after the touch is released. So I track all touches with an invisible sprite that tracks where the touch started, where it ends, how long it has been in touch, etc. My touch sprite tracker does have a boolean called StopClick just for rare cases like you mentioned...

  • The problem with strings is that the editor doesn't care what they are, so you have to manage them yourself.

    The nice thing about variables as Bool type triggers is that they do indeed act just like triggers when changed. Plus they can be compounded to simplify things like variable "touchType" >= 4, do foo, etc.

    Minification doesn't touch the developers strings, that's why its a security concern.

  • newt

    Minification doesn't touch the developers strings, that's why its a security concern.

    Right! So that would explain what Ashley said about how allowing name retrieval would make projects easier to reverse engineer.

  • AllanR

    My touch sprite tracker does have a boolean called StopClick just for rare cases like you mentioned...

    Interesting, but that you said 'rare cases' makes me wonder if I conveyed my point right... so generally I was referring to probably some 95% (99%?) of cases where all you want is tap the specific frontmost object and nothing else. So you'd just slap the StopTouch behavior onto the popup background sprite and therefore need literally zero logic/events/variables to make sure it works as expected.

    So convenient, but as said maybe that'd be technically problematic. Also I'm no longer sure, perhaps it's somehow more versatile or better the way it is for the majority of users.

  • by rare cases I meant the rare time I want to have a touch apply to multiple instances and still have it stop at a certain point.

    I agree that 99% of the time you probably just want the top instance, but it only takes one extra condition to accomplish that (Pick top instance).

    here is a sample based on the drop shadow file I made yesterday. I added my touch tracker and SpriteButtons family to show how I handle picking the top instance, using a shield to prevent clicks, multi-touch and a variety of other situations.

    you will notice that if you arrange a window to partially cover the close button of another window that the close button only goes into the Hover state if the mouse is not over the higher window. And the window blocks the drag bar and any other buttons on windows below. Multi-touch is handled properly too, only one touch can select any individual button, you can hold down one button while using others, if one touch causes another button being touched to be destroyed it doesn't freak out, etc.

    The sample also uses Font Awesome web font icons just for fun.

    https://www.rieperts.com/games/forum/DropShadow_Buttons.c3p

  • Assigning index to all the menus work fine for me. It only triggers if the index of the current active menu is equal to the index that the button is holding. Also, the new hierarchy feature is perfect for handling UI stuffs. If your UI is not dynamic, you can create everything in a starting layout and spawn the menu on demand using "recreate initial objects" action. Even if your UI has dynamic elements It's still very usefull because you have the rest of the static elements already created to serve as reference for the dynamic part.

Post reply
  • 11 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)