Holger Posted June 25, 2004 Posted June 25, 2004 Sorry for my stupid question but I can't remember the point/problem: why we can use only 1 GUI at runtime? Is it a development-thing or is it really not possible (also in the future)? Thanks and regards Holger Old project:GUI/Tray menu with icons and colors Other old stuff:IconFileScanner, TriState/ThreeState GUI TreeView, GUI ContextMenu created out of a TreeView
CyberSlug Posted June 25, 2004 Posted June 25, 2004 Just jpm/jon being lazy Just Kidding! I imagine that writing code to support multiple GUIs is quite complex.If you need multiple GUI windows, you can try multiple scripts. Here's one example; AutoBuilder is another example. Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
Holger Posted June 25, 2004 Author Posted June 25, 2004 @CyberSlug: that is what I thought maybe in the future it will be possible so long I will use a 'GUI-switching'. Thanks for your answer Old project:GUI/Tray menu with icons and colors Other old stuff:IconFileScanner, TriState/ThreeState GUI TreeView, GUI ContextMenu created out of a TreeView
zcoacoaz Posted June 26, 2004 Posted June 26, 2004 you can also make differents guis in one script using command line paremeters [font="Times"] If anyone remembers me, I am back. Maybe to stay, maybe not.----------------------------------------------------------------------------------------------------------[/font][font="Times"]Things I am proud of: Pong! in AutoIt | SearchbarMy website: F.R.I.E.S.A little website that is trying to get started: http://thepiratelounge.net/ (not mine)[/font][font="Times"] ----------------------------------------------------------------------------------------------------------[/font][font="Arial"]The newbies need to stop stealing avatars!!! It is confusing!![/font]
pekster Posted June 26, 2004 Posted June 26, 2004 Xenogis said: you can also make differents guis in one script using command line paremeters This is quite useful when you combine it with functions for each GUI. Just test the command line input at the top of your code, and link it to other functions defined below. It doesn't add that much room, and it's pretty clear what you've done when you go back to read the source. [font="Optima"]"Standing in the rain, twisted and insane, we are holding onto nothing.Feeling every breath, holding no regrets, we're still looking out for something."[/font]Note: my projects are off-line until I can spend more time to make them compatable with syntax changes.
Valik Posted June 26, 2004 Posted June 26, 2004 CyberSlug said: Just jpm/jon being lazy Just Kidding! I imagine that writing code to support multiple GUIs is quite complex.If you need multiple GUI windows, you can try multiple scripts. Here's one example; AutoBuilder is another example.If the entire GUI stuff was properly enscapulated in a class and was totally independant from everything else (Except the message pump), then it would be easy to create a list of GUI object's which are self-managed. Then the only link would be in the message pump which would only need to look at the target HWND for a message and pass it to the correct GUI object. Having not looked at the GUI source in a very long time (And not remembering it from when I did look), I don't know how hard it would be to work things into a class like that. I would expect that to be somewhat hard (or require quite a bit of rewriting) since the origins of the GUI came from Au3GUI which was written in C, not C++. I think JP did do some stuff to make it more C++, though.In any event, the first goal should be to make the GUI class as self-contained as possible. If that goal is achieved, then it's all downhill from there and it's easy to allow multiple objects to exist.But, like I said, I haven't looked at the GUI code in a long time, so this may not be as easy as one would hope.
CyberSlug Posted June 26, 2004 Posted June 26, 2004 If we were to have multi-GUI support, how would we handle functions such as GuiShow()?Currently we have GUIShow ( [timeout] ), but we'd presumably want something like GUIShow( [GuiInstance], [timeout]).... but that would break existing scripts. I suppose we could have GUIShow( [timeout], [GuiInstance]) and use a special timeout value like -1....:hmm: I'm not even sure if the timeout parameter is working right in recent builds ??? Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
pekster Posted June 26, 2004 Posted June 26, 2004 CyberSlug said: If we were to have multi-GUI support, how would we handle functions such as GuiShow()?I had that same thought when I read the previous post, and had the following idea.If and when this feature becomes something the C++ developers wish to add, another function call could be added to "switch" to a GUI for future AutoIt commands. If only one GUI is used, there is no question as to which GUI is being refered to when commands like "GuiShow()" and "GuiHide()" are used. In an attempt not to break current scripts, or add an optional paramater to the numerious functions that would have to be changed, another function could be introduced (perhaps called "GuiSwitch") that could switch between previously defined GUI's though a new return value of GuiCreate(). [font="Optima"]"Standing in the rain, twisted and insane, we are holding onto nothing.Feeling every breath, holding no regrets, we're still looking out for something."[/font]Note: my projects are off-line until I can spend more time to make them compatable with syntax changes.
Holger Posted June 26, 2004 Author Posted June 26, 2004 (edited) Thanks for your thoughts. What my wish was to show more than 1 GUI for instance to show optional parameters. so you don't have to put all controls on one GUI which is sometimes a little bit overloaded you know I think today in the evening I will play around a little bit in c++ and look what is possible. See you... Edit: now I have to clean my balcony and windows... yes - I love it... Edited June 26, 2004 by Holger Old project:GUI/Tray menu with icons and colors Other old stuff:IconFileScanner, TriState/ThreeState GUI TreeView, GUI ContextMenu created out of a TreeView
Valik Posted June 26, 2004 Posted June 26, 2004 Breaking existing scripts wasn't something I considered because it's still in testing and not final, yet.
pekster Posted June 26, 2004 Posted June 26, 2004 True Valik, but I think it would just get silly having to add in yet another optional paramater to all the GUI functions so that we could use each one with any existing GUI. It shouldn't be a required paramater, because if I only have 1 GUI in my script active at a time, I shouldn't have to define which one I'm talking to. So my point was less about breaking existing scripts, and more to point out that we shouldn't require a new method of using the GUI functions if only 1 GUI is used at a time. [font="Optima"]"Standing in the rain, twisted and insane, we are holding onto nothing.Feeling every breath, holding no regrets, we're still looking out for something."[/font]Note: my projects are off-line until I can spend more time to make them compatable with syntax changes.
Holger Posted June 26, 2004 Author Posted June 26, 2004 Did forget the TAB-control... so I can use more controls and the GUI is not overloaded Old project:GUI/Tray menu with icons and colors Other old stuff:IconFileScanner, TriState/ThreeState GUI TreeView, GUI ContextMenu created out of a TreeView
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now