Jump to content
Sign in to follow this  
deadbug

How to organise code

Recommended Posts

deadbug

I'm plugging away at my first AutoIt GUI script.

I'm looking for suggestions on the best way to organise it.

If I put it all in one source file I end up with 1100+ lines, and I still have a few screens to go and I also need to write some actions (i.e. actually make it do something at the end of the day).

The alternative seems to be to have a main gui.au3 source that then includes all the other compartmentalised bits (basically one source file per screen, one for gui-related utils, one for file handling etc.).

So how does everyone else organise things?

BTW: am I missing a really simple way to create structures (or even objects)? Right now I have a function that creates a checkbox and a couple of input boxes and a pair of clickable folder icons. I have to feed it an array (by ref) to keep the ids in (for later processing) and I have to have enums to define what's what (this id for the checkbox etc.). A structure would be ever so handy here ...

Thanks for any pointers,

-- deadbug

Share this post


Link to post
Share on other sites
Hawkwing

I always create GUIs with KODA FormDesigner (http://www.autoitscript.com/fileman/users/lookfar/formdesign.html)

Much easier!

Edited by pigeek

The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again.

Share this post


Link to post
Share on other sites
Melba23

deadbug,

I think coding style is as much a question of personal taste as anything - if it works and you can understand it when you look at it again after a period of time then it is fine. As to length, my longest script to date is 3000 lines with 12 AutoIt include files and 7 UDFs (mostly written by me). So size itself is not a bar to clear coding.

One of the many advantages of the full SciTE package (and perhaps the one installed with AutoIt, but it is so long ago that I used it, I cannot be sure it works there) is the #Region - #EndRegion directive. This enables you to break your code into regions that can be shrunk to a single line. It also forces you to compartmentalise your code - which can only help make it more understandable.

Personally I use a #Region system for all my AutoIt scripts (and something similar for all the programming I have done since I began 40-odd years ago) and a sample script would look something like this (each section is a separate region and, of course, not all are needed for every script):

SciTE Directives

Short comment on latest changes

Includes

Global declarations

Check if already running

System initialisation code

Read INI values

Read in needed files

Create tray menu

Create main GUI

Create child GUIs

Main GUIGetMsg Loop (I tend to use the GUIGetMsg mode as I prefer passing parameters rather than having lots of global variables)

Function 1 (these can also be further divided into regions if they are too numerous)

Function 2 (these can include further GUIGetMsg Loops if child GUIS are called)

...

Function n

Misc functions (these tend to be little bits of code that are used by many functions)

Help/Info

A word on comments. As has pointed out to me on several occasions, I tend to overcomment my code but I prefer to have too many comments to too few. Having had the dubious pleasure of trying to modify code written by an unknown predecessor who virtually never commented, I feel that my approach is the better. I am not suggesting that you comment every line - give the reader some credit - but make the logic and flow clear. You must explain where you could appear to have made an arbitrary decision - you may know why a certain value must be set just so, but will anyone else?

Sorry to be so long-winded, but like all things, if you can begin in the correct manner, it makes it so much easier later on.

Hope this helps. No doubt others will add their own thoughts - take what works for you.

M23


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites
deadbug

I always create GUIs with KODA FormDesigner (http://www.autoitscript.com/fileman/users/lookfar/formdesign.html)

Much easier!

I did use Koda to start off, but then I found that where, for example, I have a checkbox that decides whether two inputs and their associated folder icons should be enabled or disabled, there didn't seem to be a way to tie all that together. I may have missed a bit (I only spent a few hours playing and using it to proto some screens) but I ended up tweaking bits here and there anyway. Plus it looked like the code size would shrink and be easier to understand if I pushed things down into functions.

I might go back to it - it was certainly useful in providing a starting point for my GUI.

Thanks

-- deadbug

Share this post


Link to post
Share on other sites
deadbug

I think coding style is as much a question of personal taste as anything

I was careful not to wade in with "So, which is the best editor then" :)

One of the many advantages of the full SciTE package (and perhaps the one installed with AutoIt, but it is so long ago that I used it, I cannot be sure it works there) is the #Region - #EndRegion directive.

Ah, excellent. I'd completely missed that feature! Back to one source it is then (at least for now).

If I've missed how to have split screen viewing in SciTE, now's the time to tell me, please! (Opening a source file twice would work as long I can mark one as read-only ... otherwise you know what I'll end up doing!).

Thanks again,

-- deadbug

Share this post


Link to post
Share on other sites
Jos

I have coded the #region support in the standard lexer that comes with SciTE and is available in any editor using scilexer.dll and supporting AutoIt3.

SciTE doesn't have a multi window option. The only thing you could do is have SciTE open an new session for each file in stead of creating tabs in the same session.

To have the option to be able to open a file twice you will also have to tell SciTE not to check for that.

Have a look in the SciTE documentation for the keywords to modify. (Ctrl+F1)

Jos


SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


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
Sign in to follow this  

×