GUI's with no coordinates

[XY16]

i am a blind programmr and relatively new to autoit. i am trying to use autoit as a pose to other languages to write my gui based programs as i used to only write console based stuff. my query is weather there is a way i can create gui controls without specifying any coordinates. the only thing i have found so far is to set the GUICoordMode to 2 and use 0, -1 as the co-ordinate information, however i hae to be carefull of how long each label, button etc is or some things end up off the screen. does anyone here have any ideas?

[Melba23]

XY16,

Welcome to the AutoIt forum.

Please excuse me if I start by asking a couple of questions:

First question: are these GUIs for your own use or will they be used by other, sighted persons as well?

Second question: how are you accessing the GUI controls? Do you use a mouse at all? Do you access by using the Control* commands?

If these GUIs are for your use only, the "look and feel" takes a back seat which might make the task a bit easier. If others are to use them then we need to think a bit more about how they are constructed.

Once I get your answers, together with anything else you think might be pertinent, we can begin to think about how to get you into GUI coding. I have a couple of ideas, but I need to know a bit more before I can begin to work on how put them into action - in particular how you access the controls.

Hope to hear from you soon.

M23

[XY16]

XY16,

Welcome to the AutoIt forum.

Please excuse me if I start by asking a couple of questions:

First question: are these GUIs for your own use or will they be used by other, sighted persons as well?

Second question: how are you accessing the GUI controls? Do you use a mouse at all? Do you access by using the Control* commands?

If these GUIs are for your use only, the "look and feel" takes a back seat which might make the task a bit easier. If others are to use them then we need to think a bit more about how they are constructed.

Once I get your answers, together with anything else you think might be pertinent, we can begin to think about how to get you into GUI coding. I have a couple of ideas, but I need to know a bit more before I can begin to work on how put them into action - in particular how you access the controls.

Hope to hear from you soon.

M23

hi melba

thanks for your prompt reply.

the gui's will be for use by anyone who downloads my software, so the look and feal is quite important. my self, i use the keyboard for everything i do on the computer so look and feal will not matter to me.

the fact that the software will be used by sighted people as well means that there will need to be mouse support and the controls will have to be in logical locations.

as i am 100 per cent blind, i have no idea how to organise things on the screen, much less where they go in terms of coordinates.

once again thanks for the speedy response.

[Melba23]

XY16,

OK, now we know roughly where we start from.

Good news - we can use accelerator keys to help you action the GUI controls via the keyboard.

Functionality is more important than good looks - so do not worry too much about that at present. It is far more important to get the code working correctly - making it pretty can wait!

My initial thoughts are for you to use some form of "abbreviation" or "macro" within your editor to help you to produce standard sized controls with just a few keystrokes. Then you will have fewer problems fitting controls into a GUI as the coordinates will "interlock" if you see what I mean. For example, nearly all my buttons are 80x30, so each one takes a 100x50 block within the GUI when you add a margin around it. Other controls are similarly "sized"; combos and inputs are nearly always 280x20, edits are 280x280,....I am sure you get the idea. That should make the GUI layout much easier for you to visualise - overlapping control sis a prety big no-no in AutoIt, so we want to avoid it if at all possible. We might also look into how we could determine the coordinates for the next control automatically - but we must not get ahead of ourselves.....

So, next question (apologies for yet more, but you will have to get used to it!): what editor do you use and does it have an abbreviation or macro feature like the one in SciTE? By this I mean the ability to enter a pre-determined chunk of text when a certain key combination is entered - for example when I enter "FGC" followed by a space, my SciTE enters the basic code for a whole GUI and its While...WEnd loop; entering "BUT$" inserts a whole line for creating a standard button; and so on.

M23

P.S. If you can, please use the "Add Reply" button at the top and bottom of the page to reply rather then the "Reply" button in the post itself. That way you do not get the contents of the previous post quoted in your reply and the whole thread becomes easier to read.

[XY16]

hi melba

i am used to using notepad or notepad++ as my editor as i first learned to program in languages like vbscript, c etc and as the microsoft developer studioes are really cluttered and non screenreader friendly, i used things like molly4vb and mingw to compile my projects.

i am beginning to feel that gui's are not a blind mans cup of tea. maybe ile jus stick with tray icons and console based apps.

thanks allott for the assistance.

[Melba23]

XY16,

As you wish. If you ever feel like revisiting GUIs, you know where we are and I am pretty sure we could develop something to get you coding.

Good luck with whatever you try next,

M23

[XY16]

hi

i think i may have found a way to do my gui's? only thing is only 9 buttons are readable via my screen reader. as i can't see, could someone be kind enough to test my code?

#include <GUIConstants.au3>

Func GUITest()

GUICreate("Test gui", 800, 800)

GUICtrlCreateButton("Button1", 80, 100, 40, 40)

GUICtrlCreateButton("Button2", 120, 100,40, 40)

GUICtrlCreateButton("Button3", 160, 100,40, 40)

GUICtrlCreateButton("Button4", 200, 100,40, 40)

GUICtrlCreateButton("Button5", 240, 100, 40, 40)

GUICtrlCreateButton("Button6", 280, 100, 40, 40)

GUICtrlCreateButton("Button7", 320, 100, 40, 40)

GUICtrlCreateButton("Button8", 360, 100, 40, 40)

GUICtrlCreateButton("Button9", 400, 100, 40, 40)

GUISetState()

While 1

Local $msg = GUIGetMsg()

Select

Case $msg = $GUI_EVENT_CLOSE

GUIDelete()

Exit

EndSelect

WEnd

EndFunc

GUITest()

thanks

[Melba23]

XY16,

You needed to add a line to call the function, but the basic GUI is created correctly. However, the text is too wide for the buttons. Remember I mentioned that I use a standard 80 pixel width for buttons - that fits most text likely to be used on them.

If you want to be super clever, you could use the StringSize UDF in my sig which tells you exactly how wide any control has to be to fit a given piece of text in any font and any size - but that might be a bit of overkill!

I am in awe at what you have managed to do so far - if I can be of any help at all (such as checking GUIs like this), please let me know. Feel free to PM if you do not want to post on open forum.

M23

[XY16]

hi Melba23

thanks for the prompt feedback.

could you possibly post an updated copy of my code with width and height corrections?

thanks

you've been of great help so far

[Melba23]

XY16,

First an apology. You had indeed put in a function call - but after the function and it got lost in the post text. When you post code, it helps us sighted folks if you use Code tags. Put [autoit ] before and [/autoit ] after your posted code (but omit the trailing space - it is only there so the tags display here).

Here is an amended version of your GUI using my preferred button size and with the function declaration following the call (which is the normal convention):

#include <GUIConstants.au3>

GUITest()

Func GUITest()
    GUICreate("Test gui", 800, 800)
    GUICtrlCreateButton("Button1",  40, 100, 80, 30)
    GUICtrlCreateButton("Button2", 120, 100, 80, 30)
    GUICtrlCreateButton("Button3", 200, 100, 80, 30)
    GUICtrlCreateButton("Button4", 280, 100, 80, 30)
    GUICtrlCreateButton("Button5", 360, 100, 80, 30)
    GUICtrlCreateButton("Button6", 440, 100, 80, 30)
    GUICtrlCreateButton("Button7", 520, 100, 80, 30)
    GUICtrlCreateButton("Button8", 600, 100, 80, 30)
    GUICtrlCreateButton("Button9", 680, 100, 80, 30)

    GUISetState()

    While 1
        Local $msg = GUIGetMsg()

        Select
            Case $msg = $GUI_EVENT_CLOSE
                GUIDelete()
                Exit
        EndSelect
    WEnd
EndFunc   ;==>GUITest

M23

[XY16]

hi melba23

firstly, thanks for the updated code.

secondly, i will remember to use the insert code snippit option when posting code, but don't like the way it puts all autoit functions in as links because it makes it harder for me to copy and paste the code.

thirdly, could you post the standards for widths of other common gui controls like edit boxes, combo boxes, group boxes, check boxes, radio buttons etc?

thanks in advance

[Melba23]

XY16,

If the code tags pose a problem for you, do not use them. And I will try to remember not to do so when I post in your thread either. Perhaps you might think about adding something in your sig about it so that others who might reply are also aware.

There are no standard sizes for controls - the ones I suggested earlier are (as the White Knight said to Alice) "all my own invention". I find that it helps me to create GUIs quickly from scratch when I use the same size for controls. Many others here use Koda, a visual tool which helps you to design GUIs by allowing you to drag, drop and resize controls - but I do not feel that will be much use to you, alas. Hence my suggestion of using standard sizes so that you can visualise the entire GUI fairly easily.

I tend to use 10 pixel margins, so I size the controls 20 pixels less than a multiple of 100 and set the left edge at a multiple plus 10. Heights are slightly trickier, but I tend to use 20 pixels for single line controls like inputs and combos, 30 for buttons, and multiples minus 20 for edits and listviews. Anything to make the sums easy! And then I fiddle with the GUI when everything else is finished to make it look "pretty".

I noticed your comment on another thread about "pretty code". Believe me it helps enormously if you do set out your code in a logical and well organised manner - some of the code posted here is extremely hard to debug because it is so difficult to follow. There is a very good tool in the full version of SciTE called Tidy which does just what it says - sets all the indents, removes blank lines, standardises spellings for variables, and so on. It is often the first thing I do to code I copy from the forum!

Looking to the future, I again wonder if we could develop a tool to help you create GUIs based on some form of grid in which controls could be set - and which perhaps could give you some form of warning if you try to overlap any controls. I will think about it over the next few days. We have house guests and the Ryder Cup is starting so I will be pretty busy - do not hold your breath!

I hope all this helps.

M23

[XY16]

thanks again for the help

i will add something in my signature as soon as ive got a minute, ime pretty busy as well my self.

by the way, i was looking at some of the include files and noticed that you wrote the sound include file. i have to say, nice work. i use that particular include quite a bit my self because i like sound notifications.

do you have any idea why it is seen as a virus by some older av products? i know that avast4 doesn't like it mutch unless i remove the compression in aut2exe.

it's not a problem but my scripts get quite large without the compression, especially when i have to include bulky files.

[Melba23]

XY16,

RazerM wrote the original Sound.au3 include - I got involved because I worked out a way to get the correct length and timing for variable bit rate encoded files. It was one of the first things I contributed to the community and he kindly added me to the credits. Nowadays I have become its de-facto owner as RazerM is an infrequent visitor to this forum of late.

AutoIt is, alas, often flagged by AV apps - for 2 main reasons. Firstly, as you pointed out, using upx to compress the file often triggers a response. Secondly, the less scrupulous coders out there produce malware written in AutoIt and it gets reported - because the majority of any compiled file is the standard AutoIt interpreter stub, that is where the AV companies determine the signature and hence all AutoIt is tarred with the same brush. Jon (the original developer) has added various things to the stub to help the AV companies determine that it is the AutoIt stub and should not be used for signature determination, but it seems that a false positive is generated every few weeks by one or other of the AV apps. Some of the long-established members tried to set up a scanning and notification tool a while back to warn the AV companies about such false positive, but met with very little positive response from them. I fear we are stuck with it as long as there are the nasty litle script kiddies out there who will happily blacken our reputation.

If you would like to investigate other exe compressers that work with AutoIt, the best place to start is here - I hope you can cope with the table - please PM if not and I will try and produce a better version.

M23