you could push GUI to do what you want, but
it would be awkward, making for some complex GUI
duplicate some logic, making changing triggered rects more of a process
and it might have performance issues if you had lots of rects or units that are triggering the event
to implement this feature with GUI you'd put all your evented rects into a rect array. when a unit-enters-rect event was triggered, you'd then iterate the array until you found the rect which contained the triggering unit
i don't love this approach because you're essentially reimplementing a large part of the logic for the unit enters rect event, just to stick with the GUI toolset. at the same time, i don't hate it either, because you're not really introducing any real problems. the biggest headache will be maintaining your evented rect array, and that's not that bad
the biggest draw to this approach is that you get to keep your GUI event, which makes it simple to handle that event with more GUI code
id recommend this approach if youre either not familiar with JASS (or another programming language) or your interest is mainly making the game, rather than coding logic
It feels like I'd better just make the whole thing i jass xD
I should be possible to make it way cleaner...
maybe. it'd definitely make getting the triggering rect more elegant, but that's more for your sake as a developer than the map's sake. the GUI unit-enters-region event declares its region in an inaccessible scope, preventing you from comparing it later on via GetTriggeringRegion.
replacing the unit-enters-region event is a good use for JASS or Lua. a custom implementation will let you easily access the triggered rect from the event's callback, simply passing it as a global rect, and the custom approach will be more flexible if you have performance issues or other custom needs down the road
that said, it'll also start you down the slippery slope of managing a map that's both JASS and GUI. the biggest drawback to this approach comes from having a JASS event, your new custom unit-enters-rect event, that you probably want to handle, at least occasionally, with GUI code. how will you call the GUI code from your JASS? what once was a nicely organized GUI trigger - clearly stating its event, conditions, and actions - will now be split across multiple different components of your implementation separating the event from the rest. none of this is a dealbreaker, but it is to say that some parts of your code will become cleaner, while other parts will become uglier
some of these recommendations might be a bit out of date, but if you go this route you'll probably want to start with an existing event library, like
https://github.com/nestharus/JASS/blob/master/lua/wc3 project/Sample/mapname/src/imports/Event/script.j
you would then use it like
JASS:
globals
Event OnUnitEntersRect
unit EventUnit
rect EventRect
endglobals
//psuedo jass
private function checkRects takes nothing returns nothing
foreach unit in units-of-interest
foreach rect in rects-with-events
if unit inside rect then
set EventUnit = unit
set EventRect = rect
call OnUnitEntersRect.fire()
endif
endloop
endloop
endfunction
public function registerRect takes rect r returns nothing
call rects-with-events.add(r)
endfunction
private function onInit takes nothing returns nothing
call checkRects() every .035 seconds //this is the time rate the vanilla event is based off
endfunction
hopefully units-of-interest is a small group in your map, one that you feel comfortable managing. if youre trying to check all the units on the map then you might run into performance issues using the vanilla approach. at that point, you should start looking at auto indexers, which will essentially cache that information for you to access quickly
i also like bloodsoul's suggestion as a middle ground. by wrapping the existing
TriggerRegisterEnterRegion
logic you get the existing logic plus your custom association between the rect and its region. this option still has the same issues as the JASS approach, connecting JASS to GUI. if you want to get this working ASAP, do bloodsoul's suggestion, if you want to make a lot of weird custom shit, go this other route
if all this is sounding horrifying, then just see how far you can get on the GUI approach