I do not mean the POPUPMENU or COMBOBOX control…
I need a control the works and looks like a Popup Menuitem, but gives me access to the keys and drawing.
I thought I’d use a Listbox, but it needs to be able to extend beyond the container it is embedded in, and a listbox cannot do that
While a POPUPMENU or COMBOBOX can, I need the list to be expanded like a popup menu would, without the user having to click to expand it
The only way to have the list extend beyond the CC or even the window would be to use a small modal window.
To look good, though, it would have to be borderless and no window bar.
Perhaps using the transparent window technique to crop the undesirable parts.
We did this around a year ago on macOS and MS-Windows. Our app had the need for a custom WYSIWYG font menu similar to the Adobe suite of application. We initially looked at using a modal dialog but it just didnt look right.
We eventually ended up with a solution that works well enough and allows us to create other types of custom pop ups in the future. We even integrated it with the edit field part of the Xojo combo box so that users can filter the contents of the list while it is open.
Implementing the solution wasnt easy though. Quite a bit of time was spent working out how the built-in controls respond, writing test code, investigating solutions to various problems we came across and writing a production quality control that could be re-used and extended. It also required the MBS plugins, declares and at least one custom wndproc.
For us, all of the effort was worth it as it was going into an application used by tens of thousands of users each month. If you dont have the same requirements I would see if the much simpler solution of a modal dialog is good enough.
Using a dynamically sized transparent canvas and doing all the I/O, event handling, and painting, probably could solve that, no?
No… because like a Listbox it is constrained to the boundary of the window/container that is the parent[quote=438363:@Michel Bujardet]The only way to have the list extend beyond the CC or even the window would be to use a small modal window. [/quote]
problem there is I want a single control… you cannot (can you?) have a small modal window as a child of a container control
Change the parent?
Me.Parent = Nil // Makes the control parent the current window, not previous container
[quote=438390:@Rick Araujo]Change the parent?
Me.Parent = Nil // Makes the control parent the current window, not previous container[/quote]
that does not work… Listbox is still constrained to the container control
care to share the direction you took… if not the code?
Cant you just lock the listbox on all four sides and then resize the parent window or container instead?
@Dave S [quote]problem there is I want a single control… you cannot (can you?) have a small modal window as a child of a container control[/quote]
A Window is never a child of a Control but it does not mean that you cannot use it. You don’t even need to make it modal. However, it would need to send its “answer” asynchronously to your container.
No… the parent is basically a TextArea which may be inserted on a main window. The intent is to have a popup menu (menuitem like) but where I can change the font/size as well as react to key down within that menu…
I do not want to have two (or more) independent controls as that causes all kinds of headaches… If there are multiple custom TA instances I need multiple “menu” instances, and they need to properly reference each other… where if I can embed all the required bits inside a container control, that issue goes away.
Using Menuitem works for the most part… but I cannot make the font larger, nor can I alter its contents on the fly (filter the list as the user types for example)
I am not sure if I am understanding what you are requesting, but it sounds like something I do in my app. I have a container that includes a text field and listbox. As the user types in the text field, a listbox drops down to display possible completions based on a SQL lookup on a table. When a selection is made from the listbox, it fills in the text field and then becomes invisible.
You can see the documentation of this feature in my app here:
I developed this years ago before there were issues with transparency for control display. The only way I found around it was to place the container on the window with a height of the text field + 1. When an event occurs where I need to display the listbox, I dynamically change the height of the container so it will display the listbox below the text field.
For the most part, it works. I’m not sure if what I’m doing is advisable so I’m following this thread for better ideas.
Steve… that is exactly what I want… however… the listbox cannot extend outside of the container control (like a menuitem can)
and as mentioned before… changing the size of the container to accomodate the listbox, is the opposite of what I want… the container control doesn’t change size unless the user decides to resize things
I see. Just to be clear, my listbox does not extend outside the container. It’s just that I dynamically resize the container and have the bottom of the listbox locked to the bottom of the container. Also, in the event that changes the size, I toggle visibility on controls that are below the container that would be overlayed. Otherwise, they sometimes bleed through.
I do make sure that I place these containers with enough room to dynamically resize them within the window so there is room for the expanded listbox. That is a limitation on where they can be placed.
Just to be clear, what I described is how our autocomplete mechanism works in the IDE and it does all of the things you are describing as far as I can tell.
sorry… that isnt clear then. from you description the container/textarea grows so the listbox fits… that is not what I want
the container/textarea never changes size unless the user says so (via drag or parent window resize)
the autocomplete looks to me just like a menutitem popup,… and that is what I am using right now
[quote=438419:@Dave S]sorry… that isnt clear then. from you description the container/textarea grows so the listbox fits… that is not what I want
the container/textarea never changes size unless the user says so (via drag or parent window resize)
the autocomplete looks to me just like a menutitem popup,… and that is what I am using right now[/quote]
I’ve not done it it but maybe using a seperate (overlay, floating plain box?) window? I think that might be how Autocomplete works in the IDE… But there if I move the Window the autocomplete menu stays in the same place (IMO it should close the autocomplete menu if you move teh window- looks amateurish the way it is)
It’s not. The Xojo Autocomplete menu is a Floating Window which contains a listbox.
Thanks for all the responses… It seems that what I want to do simply cannot be done.
the end result MUST be a self contained container control with embedded Textarea and whatever else is required.
A popup menuitem does most of what I want…but since it is not a control I have access to, I cannot interecept and react to keystrokes while the menu it displayed.
I do something similar and like Greg describes its on a floating window with no border and such. I needed a better type ahead control to replace a popup menu. Since OSX has a bug or a change or something that makes populating popup menus with many rows REALLY slow. I just created the window with a text field and a listbox below it that I populated or scrolled through as the user types into the box showing the remaining part of the most likely hit in grey after the part they had entered. When the text field loses focus or the user types enter or escape I hide the window and return the result to the parent window with a delegate.
The hardest part is figuring out where to actually place the window. Has to be in the right place given the part of the parent window you want it to be over but it also cant be off the screen in any direction. That was a pain and still doesnt quite work 100% for the in every situation 