combobox pulldown screen requires the subwindow its in to encompass that size?

[SilentRuin]

For example, if I have a combobox that take up a height of 25 - I can't have the subwindow it exists in set to a height of 45 or something slightly bigger than the combobox - because when the pulldown window comes out it has to be big enough to fit that to (or auto scrolling nightmares within that subwindow start happening).

Now that would not have bothered me as it works just fine visually, but I'm just now realizing its eating all the button clicks that the "visible" part of the main window underneath the subwindow. Even though its invisible.

This is some sort of catch 22 from hell where I can't get the pulldown to yank over things (like any good pullodown will do) without the subwindow being large enough to hold it, and when I do make it large enough the invisible subwindow eats all the button clicks for things that look ready to be clicked.

I've noticed the /console window also has some kind of button click eating overlap to everything within a half inch or so of it. I figure its the same sort of thing - some invisible underlying window that is larger than the visible stuff being displayed but eating all the button clicks. Now I know the /console could be fixed as its probably just a mismatch of size, but my combobox pulldown needs room to grow that is not reserved as blank space.

So how do I get the subwindow - which is completely invisible - to stop eating button clicks (and mouse wheels etc.)?

[SilentRuin]

What a horrific experience. Am I moving past the base of knowledge here? Was first time I did not get advice. In any case, I solved it in a horrific (to me) way.

I've had to make my own copy of CoreRPG\common\scripts\combobox.lua and its template for combobox. I called it the amazingly unique name of "mycombobox".

For the record, here is what I did to solve it.

Made my own mycombobox copy of combobox template. The only difference was in the name and the script reference to mycombobox.lua file.

I then made 3 changes in my version of the LUA file...

I added this function:

local wSubWindow = nill;
local nOriginalHeight = 0;
local nExpandedHeight = 0;
local bExpandedSubWindow = false;

-- This function was added to support the ability to use comboboxes in subwindows that are stacked near other windows where you don't want it forced
-- to have the subwindow turn into a scrolling window to accommodate the combobox list when it is created. This way the actual subwindow height can 
-- expand to the given new height to allow for the dropdown list overlaying the adjoining windows. When the combobox list is shown we first expand the 
-- subwindow height to prevent the window from scrolling. The expanded size will overlap any windows below it and eat any clicks to them - we don't 
-- want this permanently to happen. So when the combobox list is hidden we set the subwindow height back to the original height. This way we get 
-- around catch 22 of either having to have a scrolling subwindow whenever the combobox list appears - or to have adjoining windows losing all their 
-- button clicks in the area the subwindow was exanded to hold the list size. 
function SetSubWindowAnchorHeights(wLocalSubWindow, nLocalOriginalHeight, nLocalExpandedHeight)
	Debug.console("mycombobox:SetSubWindowAnchorHeights called");
	wSubWindow = wLocalSubWindow;
	nOriginalHeight = nLocalOriginalHeight;
	nExpandedHeight = nLocalExpandedHeight;
end

And at the top of the showList() function I added...

function showList()
	if wSubWindow and not bExpandedSubWindow then
		-- we have a sub window so define the exapanded anchor height
		Debug.console("Set Height to expanded.")
		wSubWindow.setAnchoredHeight(nExpandedHeight);
		bExpandedSubWindow = true;
	end
...

And at the top of the hideList() function I added...

function hideList()
	if wSubWindow and bExpandedSubWindow then
		-- we have a sub window so set back to the original anchor height
		Debug.console("Set Height back to original.")
		wSubWindow.setAnchoredHeight(nOriginalHeight);
		bExpandedSubWindow = false;
	end

Then in my mycombobox named control (in the xml) I simply called the new function during my onInit()...

					function onInit()
						SetSubWindowAnchorHeights(window.parentcontrol.window.sub_mywindow, 73, 400);
					end

It's ugly.

It's horrific.

But it works.

And as nobody else had any better ideas to give me - this is what I'm going with.

[celestian]

I read your original post but I'd never experienced such a thing. Anytime I use a combobox the drop down (when not in use by user) did not block clicks where it "could" drop down/up on.

I've had many issues with the non-standard controls in FG but this isn't one of them ;(

[Moon Wizard]

Since the subwindow for the list gets created dynamically when the user clicks (at least by default); it should be the topmost control. So, I'm not sure why it would be blocked unless you are triggering an early subwindow generation, or dynamically creating controls on top of it at a later step.

Regards,
JPG

[SilentRuin]

Since the subwindow for the list gets created dynamically when the user clicks (at least by default); it should be the topmost control. So, I'm not sure why it would be blocked unless you are triggering an early subwindow generation, or dynamically creating controls on top of it at a later step.

Regards,
JPG

It's easy to duplicate. Heck, even the /console has blocked stuff around its window probably for the same reason.

And I think you misunderstand.

If you put two subwindows vertically on top of eachother (stacked not overlayed)- you cannot avoid this issue. And it must MUST be what I'm describing. Yes, the subwindow has lots of controls in it - so does the other subwindow under it. But if you put a combobox - a single line of 25 height in the subwindow - where you don't want to allocate a bunch a blank space underneath it (down list) then you will have the subwindow start scrolling to hold that list because it actually gets allocated as part of that subwindow. That is ugly and nasty and bad form. The only way to avoid that scrolling when the pulldown appears in that space you allocated for your single line (without the pulldown showing) is to make your subwindow bigger. EVEN though its invisible it still sucks up all clicks that occur in it. You can disable it and see all your controls stop processing clicks if you need proof of that. In any case, the only way to have your combobox pulldown have room to come out and play without turning the subwindow into a tiny scrolling window from hell, is to make it bigger. Its invisible after all so who cares right? Or so I thought because it was working great - till Noticed when the pulldown was not out that part of my TOP subwindow was overlapping the one below it now - to make room for the pulldown. And that overlap is where all the clicks would be eaten by my invisible window - even though it would look like you were clicking things below it - that invisible subwindow you expanded now was stealing all those clicks. Like /console probably does (you can duplicate that easy).

Bottom line - I spent two days trying to figure out how to get around the catch 22 of having my subwindow too small and turning into an impossible to read scrolling subwindow any time the pulldown came out - OR - if i made it big so it did not do that - to keep the OVERLAP of the window below by my now expanded invisible subwindow from being completely disabled by that expanded subwindow eating all the clicks.

Gist is I solve it as I described.

If you want the short explanation - having a combobox that requires space in the underlying window allocated to create the pulldown is crazy. It should be a separate window all its own if your going to play that game.

Anyway - solved it.

[SilentRuin]

I read your original post but I'd never experienced such a thing. Anytime I use a combobox the drop down (when not in use by user) did not block clicks where it "could" drop down/up on.

I've had many issues with the non-standard controls in FG but this isn't one of them ;(

Tried to explain it again above.

[celestian]

If you want the short explanation - having a combobox that requires space in the underlying window allocated to create the pulldown is crazy. It should be a separate window all its own if your going to play that game.

I agree, in standard controls in other tools it would do that natively.

I'm still not sure I completely understand your issue but I've had issues where the space in the underlying window was used to display the combobox and displace content therein. It did not block clicks however. I ended up using a cycler there but it wasn't the best option since the list is not small.

I have had panels cause the behavior you are describing and I did have to do something similar. When the panel was not visible it would change size to be out of the way. But, you know your issue better, without actually seeing whats going on I probably wont get it completely

[SilentRuin]

I agree, in standard controls in other tools it would do that natively.

I'm still not sure I completely understand your issue but I've had issues where the space in the underlying window was used to display the combobox and displace content therein. It did not block clicks however. I ended up using a cycler there but it wasn't the best option since the list is not small.

I have had panels cause the behavior you are describing and I did have to do something similar. When the panel was not visible it would change size to be out of the way. But, you know your issue better, without actually seeing whats going on I probably wont get it completely

It sounds like you just have not done the same thing so have not experienced it yet. Think of it this way (if I can do this in text):

I have a subwindow A and B (I leave the main window they both sit in for the imagination):

A1
A2
A3
A4
B1
B2
B3
B4


I've added numbers just to represent areas of the subwindows. Right now? No problems clicks in A go to A and B got to B.

But now in A4 there is a pesky combo box - which when the pulldown comes out will now force that A to become scrollable to actually fit it within its defined height so you will start to see the top disappear as the new A5 area suddenly gets created/used for the pulldown...

A2
A3
A4
A5
B1
B2
B3
B4

Annoying - where is my A1 area? It's been scrolled up off my view in the limited space of A subwindow. But wait - I'll just make it bigger so that when my pulldown comes out it will all be in my view - because I don't care that the pullown overlaps stuff temporarily below it - that's what pulldowns do. So I make it bigger...

A1
A2
A3
A4
A5 B1
B2
B3
B4

Now I never see A5 area except when the pulldown comes out. But every single click that I think is over B1 controls - is now disabled because A5 is really eating them all up. Makes perfect sense - there is a window over top of the other one - though its invisible - its still going to eat those clicks. Tried for days to send it to back - catch the clicks and pass them on - nothing worked. If A5 area overlapped B1 - B1 was dead to me.

That is the problem.

My solution is to rewrite a section of the pulldown so that it automatically changes the anchor height of A when it has the pulldown out and shrinks it back when its back in. Yes, B1 will still lose clicks when pulldown has it expanded out to A5 but when I remove A5 and put A back to 1-4 then wala. All is right with the world - all looks right when I'm doing stuff.

Disaster averted.