[quote=438419:@Dave S]
the autocomplete looks to me just like a menutitem popup,… and that is what I am using right now[/quote]
its not
its a borderless window with no title bar with a listbox inside it that is locked on all four sides just like greg described
its just coded to behave like a popupmenu
but because it is a listbox you can do just about anything
You could have a container that “owns” a floating window. The container can be invisible, only existing to give the floating window a direct reference back to the “parent” control, eliminating a lot of the headaches you’re trying to avoid. Would that make sense?
no I do not understand what you are trying to convey.
Somehow the floating window and the textarea need to be “paired” as they need to communicate with each other.
If there happens to be multiple “textarea containers” then either each needs its own floating window instance … or if they “share” a single instance, then something needs to control who is talking to whom.
Let me see if I can clarify what I’m thinking…
You would have an invisible container that can be dropped as a child of a textarea (doesn’t need to know anything about the textarea)
That container is able to display a floating window with a lisbox of the desired options. (positioned based on the container)
That listbox can send a value back to the container when a selection is made.
The container can then raise an event when it receives a value back from the floating window.
The Floating window would get a reference to the container (weakref) in order to set the result value.
This way you have a control that can have any parent and raises an event when actions occur. Sort of like a popupmenu, but not limited in the same way.
Does that make sense?
but the floating window is an independent object… and at some point the TextArea needs to know what instance of the float it is dealing with, and the float needs to know what Textarea… as a given window COULD have multiple of these TextAreas
That being said…not sure why the “invisible container” would even be required…
but again… I wanted it “self contained”… so it appears as a single custom control in the IDE, and all the developer cared about was dragging and dropping into their project…
you dont have the kind of control over menu item that you’d like to be able to make text area completely self contained
the alternative is to have a second object that each text area can create and manipulate as if it were a popup menu that you do have that kind of control over
thats what we’ve been suggesting you pursue
the alternative might be to create a xojo menu item then use declares to manipulate it as a NSMenuItem
not sure about setting the AttributedString from Xojo but that might let you get size, color etc for the menu items
doing this may allow you to use menuitem and thereby achieve the “self contained” nature you’re after
ok… as stated before… Thank you all… but it seems what I want to do cannot be done…
the proposed alternatives (with the exception perhaps of looking into NSMenuItem) are not viable for the direction this has to go
Right, that’s what I was getting at. The window and textarea don’t need to know about each other. The invisible container is just the intermediary/manager for communication.
NSMenuItem won’t work… needs to be xPlatform…
since there is no proposed solution that meets the criteria, I will just stay with what I already have working
Unless… Jim you are willing to throw togehter a small proof of concept that illustrates what you are describing
give me a minute, I’ll whip something up.
Here’s a fairly rudimentary example ListBoxMenu.xojo_binary_project
It doesn’t locate the menu based on the cursor position (that calculation is more effort than I feel like making at the moment). It also only uses strings. You could easily modify it to take row tags, row pictures etc. But the basic idea is there.
I’m honestly a little surprised how close it is to the Xojo autocomplete menu.
Just re-uploaded to fix it for Windows…
And Linux…
Why the need for container control?
A TextArea or field subclass subclass could just as easily instantiate the Listbox Window and control it… Then Dave’s customer would only have to drag an instance of that subclass onto their window…
- karen
I read his original post to mean that he wanted the menu to be independent of the textarea. The reason I was going with a containercontrol is to allow you to embed it at runtime, use its parent property if desired for positioning etc… this way, you could use it with a textarea, textfield, listbox, canvas etc.
One issue with this approach … teh main window loses focus… What is needed is a Floating window (you could age teh TextArea itself move the teh listbox curse and close or change teh menu contents if they type after hitting tab… A lot of greta possibilities…
But the issue with that is that a floating window has title bar… That could probably be gotten rid of it with declares … but the it gets OS specific …
It’s too bad and Xojo does not provide a plain box floating window style … (that is exactly why I did not create my own solution for this years ago)… It would be perfect for this kind of thing… And given how they do autocomplete, I have to wonder why we don’t have that!!!
Isn’t that part of What dog fooding is about?
- karen
Xojo IDE loses focus during autocomplete too
No … I wanted a single custom control (a container control, with a textarea and whatever else was needed)
but let me play with what Jim posted (Thank you Jim) and see if I can make it work from there…
Independent, in that it needs to be able to exceed the boundary of its container
Got it. You could just do like Karen said and make it a textarea subclass instead of a container control, and rename the events/methods to make more sense.
thanks Jim… tommorow I will see what you did