why aren't my combos working?

[human fly]

i have some combo dropdown lists, that work in Ctrlr as editor,
but do nothing, remain fixed, in the exported *.exe instance.
some work, others don’t. i’ve checked through properties, but
nothing seems wrong. i’ve brought the modulators ‘to front’.

other combos elsewhere on the panel work fine.

i can only think that one tabs group has a transparent part
overlapping where those combos are. – but they work ‘locked’
in Panel mode ticked/unticked.

• This topic was modified 7 years, 1 month ago by human fly.

[human fly]

further investigation on this:
a row of combos don’t work after i draft the exe.
they are ‘frozen’, do nothing.
other combos in different places work.

so: i copied one of the working ones, renamed, gave
it the list the other one has, and put it where the
non-working one was. that one, i moved to another area
on the group. both working at this stage: panel mode.
then: i redraft the exe – and now the new combo, in the
old position doesn’t work, and the old combo, moved to
another position DOES work.

ok, so: my positioning looks ok. i’ve tried ‘snap'(resolution
4 units), off-snap (adjusted numerically by -2 units), no
difference. i tried re-sizing the combo, no difference.
i tried moving it a bit further from the edge, bringing it
‘to front’, no difference. …what is going on?

(also: my combos normally load with a selection, i have been
getting them start up with ‘no selection’ – although this is
quickly remedied as the list is still there)

any rules to observe with combos that i’m missing ?
tricks? i don’t think there’s anything wrong with the combo
parameters, i think it is to do with its position on the
panel/within the group.

[human fly]

ok so i moved the non-working combo further up on the Group,
resaved/exported the instance, and it now works as it should/
*it appears that:

the combo will only work if a certain percentage of its dropdown
area is clear of the bottom edge of the group.

this is just my deduction, estimation.

this can’t be right. i would call it a bug.
you need to be able to position combos where you can, even if
the list drops down over the edge of its containing group.

now: is there anything i’ve overlooked? i’m going back to check
over again if there is any dimension that is causing this.

nb: i have had problems with modulator sizes before, in relation
to title size and alignment – lots of options and possibilities
there ! each behaves a bit differently, left right, top centre etc.

[human fly]

another post, cz i’ve thought of something:

the combo Group is above a Tabs, and in the Tabs transparent area,
so they must end up behind it. but i thought i’d dealt with this
already sending things ‘to front’, in order. i’m a bit anxious
about sending my main Tabs ‘to back’ in case they disappear behind
everything(..) – but i’ll give that a go. i think this could be
the problem.

….
edit: no: that didn’t work.
i thought of using a layer, but that could be complicated.
i would rather do it the way i’m doing it now.

it is a shame that the empty part next to tabs seems to
disable combos crossing over onto it. visually, it looks
ok – and i don’t want a big empty strip there. my option
would have to be to put the Tabs at the bottom, which i’m
not sure about visually. or maybe to the side? …

• This reply was modified 7 years, 1 month ago by human fly.

[human fly]

ok, i resolved this, as much as i can: the problem
is when you overlap a combo under the transparent
part of a UITab, and the mouse can’t get to it.
i rearranged the group/container above the UITab,
and other modulator types seem more tolerant of
having some of their space covered: they have value
and label areas, so you don’t need that clickable.

solved. although atom might like to think about
‘send to front/back’ being able to over come this.
it doesn’t at present, i tried.
also maybe some signifier in Properties pane to
indicate the front/back state? not essential.

[Author]

Posts