Jump to content

Recommended Posts

I think that this is a bad idea:

GUISetControl ("combo", "w=$width, data=$data ,submit=1")

If variants are to be expanded in strings, it should be a global option (Similar to ExpandEnvStrings) and not something done on a per-function basis. People already get messed up enough whenever they try to do that and it doesn't work, I don't think letting some functions do it and others not will help that any. Especially since the most likely scenario is that people will start asking for it more and more until eventually somebody has to go back and make it a global option anyway.

I still don't see why passing optional arguments isn't the preferred method, though. Why even allow multiple arguments to be passed to any function if some of the functions are going to use a string method like this? I just can't understand the logic in that being better. Not to mention that passing by arguments will be a lot faster because you don't have to do any string work. :: shrugs :: :whistle:

Link to post
Share on other sites
  • Replies 93
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

I think that this is a bad idea:

GUISetControl ("combo", "w=$width, data=$data ,submit=1")

If variants are to be expanded in strings, it should be a global option (Similar to ExpandEnvStrings) and not something done on a per-function basis.  People already get messed up enough whenever they try to do that and it doesn't work, I don't think letting some functions do it and others not will help that any.  Especially since the most likely scenario is that people will start asking for it more and more until eventually somebody has to go back and make it a global option anyway.

I still don't see why passing optional arguments isn't the preferred method, though.  Why even allow multiple arguments to be passed to any function if some of the functions are going to use a string method like this?  I just can't understand the logic in that being better.  Not to mention that passing by arguments will be a lot faster because you don't have to do any string work.  :: shrugs :: :whistle:

I agree the expansion has to be optional.

If few parameter are to be used no good position for not having to many ,-1,-1,-1 or "","","" that the consequence of to may parameter I always miss one in the counting.

for me in an anticipation to keyword generalization which is by the way much more descriptive and error free in parameter passing.

I still like to go with keyword.

For speed we don't really need speed for building a GUI that a user will wait seconds before selecting and closing.

I am more concern about the extra size of AutoIt3.exe today we have an extra 3,5K for the actual function.

Link to post
Share on other sites

I have been using Macro Scheduler and recently experimenting with AutoIt3 after seeing come of CyberSlug's postings on TextPad forum. I like what I see a lot.

I tried using the GUI stufff last night, you have many more controls, options etc. I am probably doing things wrong right now, but it was tough trying to position objects. Finally figured out what "0" and "-1" do. The Help section is not clear on this at all.

I did find it confusing where there is no consistency in the sequence of Left, Top, Width, Height. I know some are optional, but I think this is still a valid observation to be looked at.

But the biggest problem I had was trying to figure where the next object would be placed. I could do the 0/-1 OK, but really messed up with using =/- real numbers.

But as you think about methods of implementing this, let me suggest you look at the Dialog> command in Macro Scheduler to see how they implement the objects and coding etc. Just need to place, drag, resize objects and code for GUI is created automatically. Very friendly and easy to use. but limited in functionality compared to your GUIs. After this is done, you can then edit it like can do in AutoIt3 GUI Control commands. Or you can edit it with object dragging again, as in original creation.

One last comment. The latest Clip Library for TextPad does not have the GUI commands. I have been adding them myself. Are there any other functions not in the Clip Library file?

Keep up the good work, I am sure I will be a regular user.

Hope this was helpful.............good luck, Bob

Link to post
Share on other sites

Wanted to make modifications to my last posting. I now see that I was using the GUI_test vs. the Au3GUI_test last night. So my difficulties are probably not relevant at this point. I am now starting to try out the Au3GUI_test samples.

As soon as you get the latest proposal implemented, I'm starting my GUIFormDesigner...

I would still like to see an approach like that used by Macro Scheduler, where the code is written from user dragging objects around. Edited by BobHansen

Hope this was helpful.............good luck, Bob

Link to post
Share on other sites

Getting caught up with the subject. I realized that when I first read the messages on the forum they did not mean anything until I downloaded and started using the tool. I just finished reading all the messages from the beginning.

I don't know AutoIt or the GUI version well enough to suggest any code at this time, but

or something similar to Au3GUIXP which will have more "" and & if you want to compute the valueor something similar to Au3GUIXP which will have more "" and & if you want to compute the value

definitely gets my vote.:angry:

I too ran into the issue of objects moving because they were relative to other objects. The use of "shorthand" values like 0/-1 may be good for quick data entry, but they should be translated at that time into the absolute values. On the other hand, an advantage of relative positioning is that you could change values on 1 or 2 objects, and all the others would move accordingly, a potential big timesaver.

Another advantage of absolutes, as already noted, is the ability to pick up the values from other editing/design tools that will have the absolutes.

B) When the form designer comes out , then a lot of this may become easier because of the drag/drop feature and looped/tagged items that would be handled as a group. The tools for Hor/Vert alignment will also be great. with user definable grid sizes. I can hardly wait! :whistle:

I did not see any option for or help/tips or sound/media files to be triggered on gui/element focus/enter/exit/hover, etc. Would these just be provided using AutoIt functions? Perhaps could be an option on the controls, but I also prefer fewer parameters with each function. After a few blanks, it's impossible to count properly.

Thanks for listening......

Hope this was helpful.............good luck, Bob

Link to post
Share on other sites

Wanted to make modifications to my last posting.  I now see that I was using the GUI_test vs. the Au3GUI_test last night.  So my difficulties are probably not relevant at this point.  I am now starting to try out the Au3GUI_test samples.

  I would still like to see an approach like that used by Macro Scheduler, where the code is written from user dragging objects around.

I have a look to the MacroScheduler

Thanks for improving the Proof of concept

I agree the 0,-1 has to be better documented I Try in 100.3 that I will upload today

which is a complete version positional based parameters

Link to post
Share on other sites

I did not understand that this is still in POC stage. :whistle: That makes me feel even better, not too late to provide some input from a new AutoIt user. Also explains why Clip Library and Help files are so lacking. I will readjust my perspective to the different status of the two different programs...........

If you don't have Macro Scheduler, I can provide you samples and screenshots.of Dialog tools.

Any chance of getting a copy of the script for jpm's sample from 3/7?

Hope this was helpful.............good luck, Bob

Link to post
Share on other sites

Your "My test gui2.jpg"  shows the one I wanted to see. 

Or was this created with something else and being used as a sample of some of the GUI goals?

Uploaded in http://www.hiddensoft.com/fileman/users/jpm/AutoIt3-gui/

I hope that help.

I check the macroscheduler very similar with current situation when you use Opt("GUICoordMode",1) which is the default.

I agree that trying to minimise the number of parameter inverse x,y with w,h.

If we stay with the positional function It can be better to reverse the order.

BTW the order was coherent with other AutoIt3 function as SplashTextOn

Dialog>MyDialog

  Caption=This is My Dialog

  Left=300

  Top=300

  Width=305

  Height=120

  Label=Type Something Here:,5,5

  Edit=MyEdit,5,22,230,Type Something Here and Press 'Display'

  Button=Display,240,22,50,20,3

  Button=Exit Macro,5,50,100,20,2

  //Use Memos for multiline edits

  //Memo=MyEdit2,80,80,200,200,dd

  CheckBox=MyCheckBox,Play Chimes?,130,50,90,False

EndDialog>MyDialog

Link to post
Share on other sites

I check the macroscheduler very similar with current situation when you use Opt("GUICoordMode",1) which is the default.

Re this, I was not talking about the end code or its format, but the manner in which the coding is created without doing any of it manually.

I was able to create the Gui design below above by pasting the Dialog code you submitted from the previous posting into the script, selecting it, and clicking on a Dialog Design button. So from here I can move/resize objects, add/delete objects from the Toolbar, change properties by right clicking. And when done, the design can be saved for reload and/or can replace the original code. But no manual coding required. I could have started from a blank GUI window vs. pasting in the sample code you provided.

The designer looks like this for the submitted code

===========================================

Here is the toolbar:

Posted Image

And here is the original GUI (Dialog) that is being created with drag/drop tools. Objects have properties that can be assigned with right click. Controls including the GUI window have resizing handles

Posted Image

Here is the GUI in design stage after I have resized the window, repositioned a button, added a combo box and a memo box:

Posted Image

Also note that in the GUI title, the position/size parameters are shown for the selected object. That is a nice feature

And this is the code that is created when saved.

Dialog>MyDialog

Caption=This is My Dialog

Top=194

Width=455

Left=200

Height=172

Label=Type Something Here:,5,5

Label=,200,64

Edit=MyEdit,5,22,230,Type Something Here and Press 'Display'

Button=Display,240,22,50,20,3

Button=Exit Macro,333,114,100,20,2

CheckBox=MyCheckBox,Play Chimes?,130,50,90,False

ComboBox=msComboBox1,288,80,145,

Memo=msMemo1,24,88,185,57,Added this message box, made the GUI window widerto the right, moved Exit Macro button

EndDialog>MyDialog

And can just edit the code if I want, no need to use the Designer tool. And the values in the Dialog script can be variables.

Just offering a glimpse of a tool that I use now with some features that I think would work well in the Designer for AutoItGui. Easy to use, intuitive, no coding required but available if wanted. To keep in line with current GUI thoughts, this does not conflict with absolute/relative positioning, that just becomes a function of how the layout is converted to the code using the new GUICoordMode.

Hope this was helpful.............good luck, Bob

Link to post
Share on other sites

Re this, I was not talking about the end code or its format, but the manner in which the coding is created without doing any of it manually.

I was able to create the Gui design below above by pasting the Dialog code you submitted from the previous posting into the script, selecting it, and clicking on a Dialog Design button.  So from here I can move/resize objects, add/delete objects from the Toolbar, change properties by right clicking.  And when done, the design can be saved for reload and/or can replace the original code.  But no manual coding required.  I could have started from a blank GUI window vs. pasting in the sample code you provided.

The designer looks like this for the submitted code

===========================================

Here is the toolbar:

Posted Image

And here is the original GUI (Dialog) that is being created with drag/drop tools.  Objects have properties that can be assigned with right click.  Controls including the GUI window have resizing handles

Posted Image

Here is the GUI in design stage after I have resized the window, repositioned a button, added a combo box and a memo box:

Posted Image

Also note that in the GUI title, the position/size parameters are shown for the selected object.  That is a nice feature

And this is the code that is created when saved. 

And can just edit the code if I want, no need to use the Designer tool.  And the values in the Dialog script can be variables.

Just offering a glimpse of a tool that I use now with some features that I think would work well in the Designer for AutoItGui.  Easy to use, intuitive, no coding required but available if wanted.  To keep in line with current GUI thoughts, this does not conflict with absolute/relative positioning, that just becomes a function of how the layout is converted to the code using the new GUICoordMode.

Ok Bob,

So that for AU3GUIScriptWriter that Larry has in mind.

I am concentrate on what is inside the AutoIt3 internal functions.

so for inclusion of a modified GUI #include can be a solution to avoid change inside the main script.

Link to post
Share on other sites

Added to IsChanged... (the // comment should help know where)

InvalidateRect(m_hWndGUI,NULL,TRUE);

//   subclass the windows GUI to have specific handling

helps some... I just have a nagging static BK change when the MSGBOX pops up (on win98)

I will have a check what are doing my virtual OS.

I am going home so I will upload the source if different in 1 or 2h

Link to post
Share on other sites

I will have a check what are doing my virtual OS.

I am going home so I will upload the source if different in 1 or 2h

being uploaded.

Good checking.

It is supposed to be at the state we decide before yesterday

Link to post
Share on other sites

I have trouble and can't find solution :whistle:

I have found, GUIExecute stop executon until user click some control with "submit" action. But for example, I have some GUIWrite functions (or my own functions) which must work in dependence of external events while GUI is running. I can't find way to do this. I've tried to use Adlib function - but with no luck, Adlib don't work until I have press any "submit" control!

#include "GUI_include.au3"
GUICreate ("My GUI")
$aa = GUISetControl("checkbox", "Check1", 10, 30)
GUISetControlAction ($GUI_SUBMIT)
$bb = GUISetControl("checkbox", "Check2", 10, 50)
GUISetControlAction ($GUI_SUBMIT)
    
AdlibEnable("MyAdlib", 10)
While GUIExecute()
    GUIWrite($aa, $GUI_CHECKED)
Wend
AdlibDisable()

Func MyAdlib ()
    GUIWrite($aa, $GUI_CHECKED)
EndFunc

Maybe It possible to add ability that GUIExecute don't wait until user clicked control, but return value in given interval of time? Something like "autosubmit" - if nothing pressed this return -1, as with timeout, but don't close GUI. This can be:

GUIExecute ([timeout, [mode]])

where "timeout" - timeout in milliseconds

mode:

0 - close GUI after timeout (default),

1 - don't close GUI after timeout

How it can work:

While GUIExecute (100, 1) <> 0
If GUIRead() = -1 then
    [do something when idle]
Else
    [do something when user click control]
Endif
WEnd

BTW it is easy with AU3GUI(XP), because it's work independently from script, but seems impossible with current GUI implemetation B)

Link to post
Share on other sites

I have trouble and can't find solution  :whistle:

I have found, GUIExecute stop executon until user click some control with "submit" action.

You certainly reach the limit of what can be done without having a real multithreading inside AutoIt3.

I will think about, I am sure Larry will too.

Be on touch

Link to post
Share on other sites

JP, keep this in mind. This is integrated into AutoIt, meaning we have full control of what kinds of controls are created. Because of that, all the controls can be made to respond to AutoIt's already in place Control functions. With that in mind, I think that could be the primary way for the GUI to communicate back to the script.

However, I wrote some script functions for AU3GUIXP that worked EXTREMELY well for having a dynamic GUI. It has like 8 buttons, several hotkeys perform the same functions of those buttons, too. I did it by creating a hidden listbox, and then every time a button was clicked, it trigged the setdata event which Larry graciously added for me. It would append that control's text to the listbox. Every few ms, I polled that listbox to see if it was empty or not. If it wasn't empty, I got the message, deleted it from the box, then sent it off to another function for processing. What does this sound like to you? A message pump! I emulated it through clicks and a listbox.

That being said, why not create some stuff for this GUI in the same way? It should be no trouble at all to make a message queue (A small stack of some sort) and write a blocking GetMessage function. Because of the level of integration, you could actually do better than just return the text of the control, but actually return references to the objects or anything you want. This would be even better than using AutoIt's Control Commands.

In short, what I'm trying to say is desgin a way for message pumps to be emulated. It really does allow for highly interactive GUI's.

Edited by Valik
Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...