What are Dim, Global, Local, and Scopes?

[onlineth]

Hi, I am having issues understanding something in the tutorial Melba23 gave me. At the bottom of page 22-

When declaring variables you have the option of declaring it in 3 scopes-
• Dim
o Local scope if the variable name doesn't already exist globally, where it is then global.
• Global
o Forces creation of the variable in the Global scope
• Local
o Forces creation of the variable in the Local/Function scope.
You should use Local or Global, instead of Dim, to explicitly state which scope is desired for a variable/constant/array. Examples of declaring variables are shown below:

Dim $x, $y, $z ; Notice we can declare variables of the same scope on the same line if desired.
Global $RADIUS ; Global Variable
Local $_daysWorking ; Local Variable

 

What are Dim, Global. Local, and Scope? What do they do?

[jchd]

Look up one of these keyword in the help file and read on.

[TechCoder]

also being new to autoit, I, too, am having challenges understanding what these are/do, though I have found the best teacher to be experience in this matter (I read all the materials and still was left with questions.

So, I went into the SciTE editor, copied over some files from the Help and ran them, changing Dim, Local and Global around a bit to see the difference.  Most of the time, there isn't much difference you can see, but after writing my own program and putting all of these to 'Global' (I had thought, why not, "Global" sounds good - I can use them anywhere and not have to mess with all this again!") - well, let's just say that setting everything to Global is NOT a good idea!

So, what is the right idea?  When do you use which one?

Again, I'm no expert, but here is how I am currently seeing these work:

Global - use when you really (and I mean 'really') need to have a variable available anywhere in your code.  Sparingly is a good thing to think about here.  I don't know why, but using it all the time does cause problems, so I use it now on just a few things that I have to have and it works better.

Local - use this "all the time" - it is good for things you need to declare for something 'small', like something you use in a function.  My current thinking (as/until I learn more) is to write my programs with Local on all variables then 'see what happens' and when an error shows up on that variable, I try Global.  Most of the time now (after just a few programs) I am learning how/why/when Global should be used, but still I fall back to this as a first step.

Dim - well, so far, I haven't had to use it so I don't know much about it (and I'm well into my 5th autoit program and in this one I have nearly 3000 lines of code).  I'd say it isn't as required as the others, though I'm sure it has valuable reason for being.  I have used ReDim quite a bit, which resets the size of arrays. 

That is a 'newbie' look at these commands.  Like all, though, the more you program and practice, the more likely you will NEED one of them - that is when you really learn about them (i.e., my recommendation is to get out of the books and into a PROJECT of some sort - makes you dig in a different way.)

[Melba23]

onlinethlive,

I recommend the Variables - using Global, Local, Static and ByRef tutorial in the Wiki - I wrote it to answer the very question you are asking.

TechCoder,

Your summary is pretty close to the truth - well done if you worked all that out empirically.

M23

[guinness]

I am late to the party I see. This is my favourite subject in AutoIt.

[TechCoder]

onlinethlive,

I recommend the Variables - using Global, Local, Static and ByRef tutorial in the Wiki - I wrote it to answer the very question you are asking.

TechCoder,

Your summary is pretty close to the truth - well done if you worked all that out empirically.

M23

Nice tutorial - hadn't seen that page - learned a lot about what, to me, has been the most confusing part of moving to AutoIt.

I come from years in php - tossing variable names in/out/around at whim (and often getting lost in a mistyped letter that takes hours to find..... - one of the things I really like about AutoIt is helping me catch that stuff).  From the tutorial I see that AutoIt actually gives Global to variables in the script and Local to function variables - I've taken to using the AutoItSetOption("MustDeclareVars", 1) directive to help break myself of willie-nillie naming (and have seen my code tighten up dramatically - finding that using ONE Global variable called $temp very useful for doing minor checks that I only need for a couple lines.  Sure keeps the page cleaner!

One thing, though, from the tutorial that I still don't quite understand is shown below

Foo()
 Foo()
 Foo()
 
 Func Foo()
    ; Set the flag only on the first entry into the function
    ; This assignment will be ignored on subsequent entries
    Local Static $fFoo_First_Pass = True
 
    ; Check the flag
    If $fFoo_First_Pass Then
        ; Immediately clear the flag to prevent running on subsequent passes
        $fFoo_First_Pass = False
        ; Run on first pass because flag is set
        ConsoleWrite("First pass" & @CRLF)
    Else
        ; Flag remains cleared for subsequent passes
        ConsoleWrite("Not first pass" & @CRLF)
    EndIf
 EndFunc   ;==>Foo

I believe I understand it now (though just looking at the code, it certainly requires an understanding of the Static declaration), however, I was confused by the text

 

You can assign an initial value to this variable when it is created - if it is already in existence then the assignment is ignored

Perhaps (at least, for me), it would be more easily understood to change 'assignment' to "re-assignment attempt" - or something like that.  What I thought, at first, is that the INITIAL assignment is ignored, though that would, of course, negate the function of Static....  

Anyway, I now understand what it can do - just have to find a great use for it, then use it over and over a few times - in the meantime, I'm bookmarking that page!

One other 'take away' from reading this tutorial that I really was happy to get clear is the ByRef.  That had me totally baffled until I read this.  Now, I see why all the 'pros' using AutoIt run everything in functions - I was just making main code with functions as a by-product (php style I have used for years).  ByRef can certainly be used to great advantage - though I am not planning to go back to all my previous AutoIt scripts and change things, I am going to be using these powerful tools to make things easier in the future! 

One question that came to mind in digesting all this (and it has a direct reflection on the project I'm working right now) - what is the 'best practice' and 'fastest', perhaps 'prefered' (terms that are, I know, difficult to scope, however.....) way to manipulate data of small-medium (in my world) lists of text (in this case, the 'core customer' will often be dealing with some 50k songs - not very big, though some will reach in the 100K - 200K range and I wonder more about if my code is right for them).  

I read the filenames, dissect and manipulate them in various fashion (breaking out the Artist, Title, etc.), then rename/manipulate as/when needed (fixing caps, spelling, fname/lname switch around, etc.)  Lots of features/functions, though lots of potentially wasted time doing too many disk writes).  I wrote all this in php and was very satisfied with the processing times I got using MySQL on a local server base, though when I found how unsecure it all was, I got into AutoIt and am porting everything over.

I'm getting fast times using SQLite (thanks to a tip from the forum to use BEGIN/COMMIT - brought the time to process the list down about 90%) - ~30 seconds to do the first run for 32K files (compared to the MySQL times of ~30 seconds to do all the runs, it is quite a bit slower, though 'acceptable'.)

I'm wondering about holding 'all that' data (perhaps it isn't much in today's world of multi-gig memory??) in arrays when there is 5X that.  I've not run into any problems with my 'small' list, but I am doing a 'safety save' of the data in the middle of processing to make sure we have the changes, then reading it back to a clean array (in a slightly different, smaller manner - that could easily be taken care of in memory) before going on with the re-work part of the program to make sure the larger data sets are as protected as possible (of course, the customer will let me know if things crash!).

Any tips on how 'best' to handle things are much appreciated.   (and, sorry for swinging the topic a bit, though I believe the original question is answered)

[AZJIO]

[jchd]

If you're concerned by SQLite speed on such a tiny DB which you want persistent, you can always make good use of my SQLite Backup UDF which allows copy of databases to/from memory very easily. This way you can "backup" the disk DB to memory, perform any action on it and back up to disk once done. Of course while you're working on the memory DB, a power outage will loose changes but it's up to you to perform intermediary backups to disk to protect against such issues.

[TechCoder]

If you're concerned by SQLite speed on such a tiny DB which you want persistent, you can always make good use of my SQLite Backup UDF which allows copy of databases to/from memory very easily. This way you can "backup" the disk DB to memory, perform any action on it and back up to disk once done. Of course while you're working on the memory DB, a power outage will loose changes but it's up to you to perform intermediary backups to disk to protect against such issues.

I had seen the UDF (in one of my searches around), and have considered it, though haven't had the time to learn about it along with all the other new things I'm digesting (sometimes I feel like I'm getting fed info about AutoIt about as fast as a whale scooping up krill - though still in human form.......) - it is on my list of things to study further and I will likely use the UDF - moving from disk to memory was my first thought when I had some speed issues, though the tip on BEGIN/COMMIT (I think it was from one of your posts - seeing the avatar, I know I've read a lot of your info) worked very well for my current project.

Your comment about 'such a tiny DB' also encourages me.  The world I've been around calls 50k records (of 20-30 columns with various data up to 300 characters) 'big' - I've always felt that a few times that is 'medium' perhaps, though I have seen discussions on millions of records being considered 'small'.  It all depends on your project and point of view, though with my current skills and knowledge, I would not consider using AutoIt with SQLite for such a database in my project, which is not a persistent DB, it is rebuilt from filenames on every run (the only way we can guarantee the data and then properly manipulate it).  We aren't doing a 'build it and then search many', we are (simply?) processing current filenames, manipulating the data, reformatting according to various rules and options, then updating the file names to be in a consistent manner.  The process is only run a few times and all filenames are updated, so 'long' process times of 3-5 minutes isn't horrible.  One similar product takes up to 20 minutes to update their database, so I'm not unhappy with my times, just looking for ideas on if I'm burning up resources I shouldn't.  Seems I'm in the ballpark though.

I will look at the UDF again as I get the project nearer completion (i.e., finish all these last features up, clear some bugs, etc.) - for now it may become a future update function.

While we are on the 'speed' discussion, I do have an issue with processing that I was thinking of making a new topic with - if that is best, let me know.

While I'm running a process (reading the filenames, manipulating them, etc. - all in AutoIt and memory (i.e., no disk activity), though building the SQLite commands, if I go to another program (while I'm waiting I read forum posts, help files, etc. to learn something else, or do a bit of coding - whatever), it seriously affects processing time.  Again, I'm used to php and server processing in the back-end, with massive processing power, multi-tasking, etc. going (I'm not all that familiar with the details, but I know it is a different method altogether than GUI and user-side processing) so never worried about such things, but my time to process some 30000 records I have in a test base goes from ~3 minutes (when just watching the program) to  L O N G  - sometimes 10+ minutes or more when I am off looking at other things.

I know this has to do with keeping window focus on the process - I can, at any time, click on the progress window and it speeds up quickly (I have it updating a progress meter with 'time spent' every few hundred records to see the progress) and I wonder if I could/should use something like (I know this is not the program and I will figure out all the correct commands, I'm just wondering if this is the right approach);

Local $mywindow,$activewindow
while 1
   $activewindow = _WinAPI_GetFocus()
   If Not $mywindow Then
      Static $mywindow = $activewindow
   EndIf
   _WinAPI_SetFocus($mywindow)
   ; process a bit - maybe a few hundred records = ~ 300ms
   _WinAPI_SetFocus($activewindow)
   If (identify 'all records processed') Then
     ExitLoop
   EndIf
WEnd

to keep the focus 'somewhat' on my program (allowing the user to do other things, though with an understood 'cost')

Perhaps WinActivate is more correct, etc. - again, I am not asking for a written program, I'm happy to do that, just want to understand if I'm on the right track with the best method to pursue (i.e., 'focus switching') when I get to the point this feature moves up on the priority list.  I do a lot of 'look-ahead' thinking on every program part, when I see a potential for a customer complaint I try to make sure I know the direction that I need to study long before getting into that part of the programming - to me, that is 'best practice' instead of waiting until it is urgent and then having to piece-meal some bit of patch-up code to cover - and.....  worse thing ....having to go back and fix all the mess later.

We are currently covering this 'known issue' with documentation (stating that they need to stay on this window or processing time will suffer) - or is there some other way to achieve the same/better results in AutoIt?

[onlineth]

also being new to autoit, I, too, am having challenges understanding what these are/do, though I have found the best teacher to be experience in this matter (I read all the materials and still was left with questions.

So, I went into the SciTE editor, copied over some files from the Help and ran them, changing Dim, Local and Global around a bit to see the difference.  Most of the time, there isn't much difference you can see, but after writing my own program and putting all of these to 'Global' (I had thought, why not, "Global" sounds good - I can use them anywhere and not have to mess with all this again!") - well, let's just say that setting everything to Global is NOT a good idea!

So, what is the right idea?  When do you use which one?

Again, I'm no expert, but here is how I am currently seeing these work:

Global - use when you really (and I mean 'really') need to have a variable available anywhere in your code.  Sparingly is a good thing to think about here.  I don't know why, but using it all the time does cause problems, so I use it now on just a few things that I have to have and it works better.

Local - use this "all the time" - it is good for things you need to declare for something 'small', like something you use in a function.  My current thinking (as/until I learn more) is to write my programs with Local on all variables then 'see what happens' and when an error shows up on that variable, I try Global.  Most of the time now (after just a few programs) I am learning how/why/when Global should be used, but still I fall back to this as a first step.

Dim - well, so far, I haven't had to use it so I don't know much about it (and I'm well into my 5th autoit program and in this one I have nearly 3000 lines of code).  I'd say it isn't as required as the others, though I'm sure it has valuable reason for being.  I have used ReDim quite a bit, which resets the size of arrays. 

That is a 'newbie' look at these commands.  Like all, though, the more you program and practice, the more likely you will NEED one of them - that is when you really learn about them (i.e., my recommendation is to get out of the books and into a PROJECT of some sort - makes you dig in a different way.)

Thank you again:)

[jchd]

First, if your DB is temporary, why do you disk-base it? Simply open a memory DB (no filename or ":memory:") and you'll get as much speed as possible without having to tweak parameters. You still can save it to disk before program termination if you see fit.

Y

ou say 50 K rows of 30 column with average 200 characters. 50 K * 30 * 200 * 2 = 600 Mb, which is pretty compatible with todays PCs. Up to you to decide whether your clients are memory-bound or not.

Anyway, switching to another task shouldn't affect performance significantly, provided your application uses the correct GUI processing. It all depends of how you allow fetching filenames, massaging that data and inserting in the DB while processing Windows messages. Perhaps using OnEvent mode is better for you. Here I assume that processes priorities aren't "tweaked".

Ouch! We're seriously hijacking this thread. Start a new one before we get banned!

Edited January 19, 2014 by jchd

[TechCoder]

 

Ouch! We're seriously hijacking this thread. Start a new one before we get banned!

Been doing a lot of testing and some tweaking on my own before bugging you more (you gave me a lot of ideas!)

New thread at