If <exp> then #Include

[BabyG]

At the present time I have a file with the following code. I have some autoit files which handle certain screens during an installation... these files are included into one main file which runs them all. The problem is after an installation i need to reset windows. To solve this i have put if statements and grab the first argument entered during execution. When executing the file an argument is entered at the end which is the line number to execute. The code is as follows.

#include "#functions.au3"

If $cmdline[0] = 0 then
    $line = 0
Else
    $line = $cmdline[1]
EndIf

If 1 < $line then
    #include "SetupInteractive.au3"
EndIf
If 2 < $line then
    #include "SetupWelcome.au3"
EndIf
If 3 < $line then
    #include "SetupRegistration.au3"
EndIf
If 4 < $line then
    #include "SetupCompleteInstall.au3"
EndIf
If 5 < $line then
    #include "SetupFinish.au3"
    ResetAndRun( @ScriptFullPath, 5
EndIf
If 6 < $line then
    #include "RunApplication.au3"
EndIf

The problem is this is very messy just so i can start executing on a specific line. The way i wished to do it was as follows.

;functions.au3
Func IncludeLine( $include, $line, $currentline )
    If $line < $currentline then
        #include $include
    EndIf
EndFunc

;script.au3

If $cmdline[0] = 0 then
    $line = 0
Else
    $line = $cmdline[1]
EndIf

Include( "SetupInteractive.au3", $line, 1 )
and so on.....

This would be much cleaner... but #include $variable doesn't work. Also another cleaner way of doing this would be to use goto... i can understand why goto has been taken out, not even I like to use it, but I think this is an acceptable situation to use it. Also maybe an include or runscript function might be needed for situations like these... that way I can then use variables to include .

Anyways... does anybody have a solution for me that does not use If statements or select case statements.

P.S. If 1 < $line then #include "SetupInteractive.au3" would be a acceptable way of doing it too... but that don't work.

P.S.S. The reason I'm worried about the if statements is because I will be creating alot of files similar to this... I don't want to have a file 100 lines long when it can be less then half that. It makes it much harder to read and debug.

[Insolence]

Includes are included before the script has even been 'started'

I believe the term is 'preprocessed'... so you cannot put variables into them.

EDIT:

BTW, many scripts I make are atleast 300 lines, almost always one file. I'd say that's about the max length for a file. Using too many includes complicates things.

Edited February 10, 2005 by Insolence

[Lazycat]

Frankly, I'm don't understand you problem and how/why goto should be really better then select/case. Yes, case statements will be twice longer, but it's absolutely easy to read. I don't know you goal and what includes contain, but if you want simplify script, maybe other ways will be suitable, for example why not to use only one include with few functions and call them?

; include.au3
Func Func0()
...
EndFunc

Func Func1()
...
EndFunc

;main.au3
If $cmdline[0] = 0 then
    $line = 0
Else
    $line = $cmdline[1]
EndIf

Call("Func" & $line)

[MHz]

Includes are included before the script has even been 'started'

I believe the term is 'preprocessed'... so you cannot put variables into them.

EDIT:

BTW, many scripts I make are atleast 300 lines, almost always one file.  I'd say that's about the max length for a file.  Using too many includes complicates things.

<{POST_SNAPBACK}>

hmm, is that right?

[SlimShady]

hmm, is that right?

<{POST_SNAPBACK}>

The first part is true.

Wherever you put #include <file.au3>, AutoIt3 and it's compiler insert

the entire contents of the specified file at that location.

If the included file contains functions and you put #include <file.au3> in a function things will go wrong.

Just some info.

The following is useless because all the "include" files will be included/inserted.

NOT because all statements are false, but it's the way AutoIt works.

As many programming languages do.

If 1 < $line then
    #include "SetupInteractive.au3"
EndIf
If 2 < $line then
    #include "SetupWelcome.au3"
EndIf
If 3 < $line then
    #include "SetupRegistration.au3"
EndIf
If 4 < $line then
    #include "SetupCompleteInstall.au3"
EndIf
If 5 < $line then
    #include "SetupFinish.au3"
    ResetAndRun( @ScriptFullPath, 5
EndIf
If 6 < $line then
    #include "RunApplication.au3"
EndIf

Edited February 10, 2005 by SlimShady

[lupusbalo]

@babyG

Don't know if that'll help, but you should understand the following:

- #include or any #statements are not "strictly speaking" part of AutoIt langage itself. they are "compiler directives" processed at COMPILE time

- if then ... statements are actual AutoIT instructions that are processed at EXECUTION time

- so instructions like

if condition then
     #include .....

... have no meaning at all!! sorry!!! :">

- you think it make sense may be because you directly "run" an xx.au3 file but if you compile it as an EXE may be it's more understandable : if a script is run as compiled EXE file, all routines you may need should be included in the executable ou "externaly run" or "called" (eg DLL)

- except with very specific langage such as "Forth" (a great one) you can't invoke the parser/compiler at execution time. This is why you need somme workaround such as Eval(..) functions in AutoIt to actually "compute string expressions" at execution time

- may be conditional preprocessor directives (as in some other langages) could be useful (and may be implemented in AutoIt compiler one day or another). But remember, if this occurs it will allways be a COMPILE TIME facility.

- if you really want to do that, (i really don't understand WHY? ) the only way could be to explicitly invoke the AutoIt compiler, compile some AutoIt stuff then run them (also look to _Execute.au3 somewhere else in the Forum)

- YES such a function should be nice in some case, but...its not in today, and as far as i understand, will probably never be because it's not inherent to its "philosophy"

hope this help

It seems VERY SOPHISTICATED i'm sure there are MANY other ways to solve your problem with AutoIt

regarding GOTO's: <not be rude ON> GOTO is MESS <not be rude OFF> just forget them

Modern langages, hapily never use goto's and don't have them

don't ask why, just IT IS

Edited February 10, 2005 by lupusbalo

[BabyG]

Hey guys

Thanx... ok... lets explain why I'm doing this and what I'm using the include statement for. Yes I totaly understand why include statements can't be variables, include needs to know what is to be imported into the exe.

Ok yes I know what include statements are for and what they do... I've done a little C/C++ programing. USUALLY include statements don't react to anything but the compiler and are included. But think of AutoIt's include as a "runscript" type function. Whether autoit was ment to work that way or not, it does. So if i have 2 files as the following, this will work...

;file1
if cmdline[1] = "yes" then
    #include "file2.au3"
endif

;file2
msgbox( 1, "YES", "cmdline[1] was yes" )

That works... I know... If cmdline[1] does not = 1 then it won't run file2. I'm using the same method now. I don't care if it's ment to work or not... it does... no problems... and yes I agree with those of you that think this doesn't work, it shouldn't. Like you all said... #include is computed by the compiler, it doesn't matter where it is (or if it does, only for error checking). I AGREE... but those of you that said it doesn't work........ it does... , trust me. I've run an autoit exe with the number 3 as an argument... it included only the lines that were 6 or more. If it included any lines before hand it would have executed exes all over the place.

Btw... <not be rude ON> GOTO is MESS <not be rude OFF> ... lol... agreed... and I'm sorry for commenting about goto... i know... it's awful... there has only ever been 1 peice of C code I have ever seen which has an exceptable use of it... all other code I've seen with it sux . Goto is not the key in this case... I'm sorry.. was just frustrated and gave up (went to the goto ).

Ok also I do know the way I'm doing it is wrong and I will change it for sure.. definitly. But my question is... how.... maybe functions is the key I guess.

My problem is as follows. I am trying to complete the following task... install an application, use the application, and uninstall the application. Now I want to have some sort of nice set out for this stuff... coz my #functions.au3 file alone is 598 lines, and that is with no spaces except between endfunc and the next func. And that file is still growing. I have other files... usually only 30 lines in size which handle 1 window (yes I know... that's not much for one file... I think that's where I can fix it ). The reason I have 1 file per window is because that window make come up more than once.... for eg... many screens during the install also come up during an uninstall.. so I may want to call them twice. Now the other thing I want is for anybody to be able to goto a computer... create a script that's 10 or so lines long.. and it will install an application for them, or potentually do whatever they want aslong as there is a script that handles the window (what they want to do in the window is defined in a ini file which contains options for the user to define).

BLAM... the obvious solution has come back and slapped me in the face. *shakes head* sorry guys, stupid me!!! FUNCTIONS DERRRRR!!!! Keep the functions script as is... but combine lots of the little scripts together into one file and make functions. So in the end i'll have about 12 functions in a file (over 300 lines.. but that's ok)... have about 5 or so different files, and when I need to use them... just include that file and use the functions... ok... BAM *problem slaps me in the face again*... Same problem !!!!!!!! DAM!!!!

Ok... let put it this way... example code is in need... remember what I said.. I want anybody with minimal experiance in programming to be able to write a file similar to this and run it!!!

#include "#functions.au3"
#include "#setup.au3"

SetupInteractive()
SetupWelcome()
SetupCompleteInstall()
SetupFinish()
SetupWait()
SetupWelcome()
SetupCompleteInstall()
SetupConfiguration()
SetupFinish()

GOT IT!!!! Text file is the key !!!! I read the text file... run Call ( "function" ) for whatever I read (error handling for exceptions of course.. and blam... works . Ok but now I'm back to using include wrong again... lets explain.... (explaining... not writing the code)

Read line from file....

if $line = "setup" & * (wildcard) then

#include "setup.au3"

endif

Call( $line )

Now I could just include all files I guess.. but that'll include thousands of line of un-needed code and slow things down... some machine that this will be run on are Pentium 2 and pentium MMX... DAM. That'll slow things down right?

Ok question is back to the start again I guess.... how can I choose which files to include and which ones not to include? I can do it my way...

If bla bla then

#include bla

endif

But that isn't clean... right... and shouldn't be possible... but it is. I guess there is nothing at this point I can do (if the code is to be correct) but include them all i guess. Any ideas? P.S. Thanx for reading ALL of this... thanx heaps for the help guys... i need a kick in the head sometime... i get lazy with my coding .

[Domonoky]

Hi...

puh.. very long post :-)

Jeah i think putting you windowhandling into a function for every window would be good.

And you could also put every function into another au3 file, so you include only the functions you need. So you get somethin like:

#include "Interactivfunctions.au3"
#include "Welcomefunctions.au3"
#include "Finishfunction.au3"
..
..


SetupInteractive()
SetupWelcome()
SetupCompleteInstall()
SetupFinish()
SetupWait()
SetupWelcome()
SetupCompleteInstall()
SetupConfiguration()
SetupFinish()

..and for your "trick"

If bla then
#include blah
endif

this will not save you any line of code in your executable , because the #include directive will be replaced.. so its the same as:

if bla then
  <content of included file>
Endif

and .. modern Computers are fast enough, so you will not mention if there are a few thousand lines more of code or not.. even on a Pentium 200 thats not the problem..

mfg Domonoky

[SlimShady]

@Domonoky

Very well said.

Edited February 11, 2005 by SlimShady

[jdickens]

To Original Poster:

I wouldn't worry too much about whether you must put many includes in your script. They are really there only as a convenience to the programmer (you) to reuse and organize your code.

What I thought you were originally asking for was polymorphism, where you might have the same fn in multiple different included files, and only call the necessary included fns when the situation warrants it. That, I don't think you can do with AutoIt.

I am not sure at what level of newbieness you are approaching the problem, so I will point out another possible solution which is why AutoIt is so effective IMHO.

Pseudocode:

While $IWantMyProgToRun

IF WinExists($SomeInitialWindow) Then

;Do stuff

endif

WinWaitActive ($TextOfAStartupWindow)

If WinExists($TextOfAStartupWindow) Then

;Do next stuff

;etc.

WinWaitActive($TextOfAFinalWindow)

IF WinExists($TextOfAFinalWindow) Then

$IWantMyProgToRun = False

;Run Application X

Wend ;$IWantMyProgToRun

In other words, respond to the windows environment.

As for the users making up scripts -- it would be sophisticated, but they could choose from a specific set of commands you create, like AffirmAllInstallationDialogs() or PutInDefaultUserInfo(), and these are accessed by your script which might be set up like:

IF $UserChose = "AffirmAllInstallationDialogs" Then

AffirmAllInstallationDialogs()

etc.

I am a mere newbie too, but I am interested to help.

J

[Blue_Drache]

#include "#functions.au3"

If $cmdline[0] = 0 then
    $line = 0
Else
    $line = $cmdline[1]
EndIf

If 1 < $line then
    #include "SetupInteractive.au3"
EndIf
If 2 < $line then
    #include "SetupWelcome.au3"
EndIf
If 3 < $line then
    #include "SetupRegistration.au3"
EndIf
If 4 < $line then
    #include "SetupCompleteInstall.au3"
EndIf
If 5 < $line then
    #include "SetupFinish.au3"
    ResetAndRun( @ScriptFullPath, 5
EndIf
If 6 < $line then
    #include "RunApplication.au3"
EndIf

I'm just taking a stab at the original code. It's messy in and of itself....

If 1 < $line then
   SetupInteractive()
ElseIf 2 < $line then
   SetupWelcome()
ElseIf 3 < $line then
   SetupRegistration()
ElseIf 4 < $line then
   SetupCompleteInstall()
ElseIf 5 < $line then
   SetupFinish()
    ResetAndRun( @ScriptFullPath, 5 )
ElseIf 6 < $line then
   RunApplication()
EndIf

Select/Case/Endselect would be just as valid and easy to read.

[BabyG]

As for the users making up scripts -- it would be sophisticated, but they could choose from a specific set of commands you create, like AffirmAllInstallationDialogs() or PutInDefaultUserInfo(), and these are accessed by your script which might be set up like:

IF $UserChose = "AffirmAllInstallationDialogs" Then

  AffirmAllInstallationDialogs()

<{POST_SNAPBACK}>

Yep... that's what my plan is... functions... that a user can call, then just compile and blam.. all done.

Just to note, the complexity or this task using autoit is my largest... but not my first. I originaly designed code that already does some of what I want to do now, with exception to a few factors.

1) in my original script i used title names... in my new script I do not... this has to be done as i will be installing the software in many different languages... so now i use Window/button IDs.

2) My original code had minimal logging, and was hard to debug. The new one has logging in most functions... therefore the code can be debuged by just quickly looking directly at a text file. Plus if somthing goes wrong (or right) you can make sure it all happened.

3) This code is made up of many many functions, most of which use other functions which use other function and so on. It makes changing code, and creating new scripts so so so much easier. The old code was just one file.

4) These scripts read configuration information (for eg. application folder) stored in a ini file. Awsome , this means anybody can change that file, run the script and it will configure anything you could normaly.

5) plus much more!!!

Ok my original comment:

guess there is nothing at this point I can do (if the code is to be correct) but include them all i guess.

Yea I know this can be loaded by all pcs ... I'm just a clean freak when it come to coding... I don't want anything to load that isn't needed. Yep... I'm just gonna load it all!!!

Ok... my final idea!!! ... I'm worked it all out... makes life simple !

We have: (note spaces and tabs didn't work and were all deleted . This was a diagram.)

/EXE FILE \

| FUNCTIONS.au3 |

| / | \ |

|(these are just a few) Install.au3 run.au3 uninstall.au3 |

\_______________________________________________________________/

Install.txt Run.txt Uninstall.txt

WhatToDo.txt

OK... and what they contain

FUNCTIONS.au3..... yep contains functions for me to use.

Install.au3 contains all the installation functions:

func SetupInteractive()

bla bla bla

endfunc

func SetupWelcome()

bla bla bla

endfunc

func SetupRegistration()

bla bla bla

endfunc

ect...

Install.txt contains somthing along the lines of:

SetupInteractive

SetupWelcome

SetupRegistration

Reset

SetupFinish

ect...

WhatToDo.txt contains somthing along the line of:

Install

Run

Uninstall

OK!!! DONE... What happens is the exefile will be setup to open file = cmdline[1], or in this case WhatToDo.txt. WhatToDo.txt will be opened by the exe ad the exe reads the first line... if this line was to be "Install" then the exe would look for a file named Install.txt. That file will then be opened and would read the first line and CALL it. If the first line was to equal SetupInteractive then the exe would CALL "SetupInteractive". By using text files in this way... not only can sombody with the compiler not installed change it (because none of them will), but if the install.txt was

SetupInteractive

SetupWelcome

SetupRegistration

Reset

SetupFinish

Then when the reset function runs it records the line it was on... creates a bat file with the exe as a file to run with the params "WhatToDo.txt" "1" "5" Which tells the exe... start WhatToDo.txt from line 1 and start line 1 from line 5. So therefore it would read WhatToDo.txt line 1 which was install. Then it would open install.txt and start from line 5 (SetupFinish). Which solves the reset problem!. Also most chances made the the install setout can just be done in a text file by a normal user that has no AutoIt3 experiance.

P.S. By the way... summery... the include saga all started in my first post because I had code in the file (which wasn't in a function in the file). Therefore when the file was included it ran. Now I'm wanting to move everything over the functions... makes more sence.... plus allows me to do everything properly and easily and cleanly. A user can specify which functions to run by introducing a text file that has a list of the functions to run and in what order. Another text file can be added ontop of that which tells the application what text files to include.

P.S.S. I'm just going to include all au3 headers.

Edited February 12, 2005 by BabyG

[Wolvereness]

The best way to do this is take whatever is in that file and copy+paste. Sooner or later that is what would happen.

300 posts w00t

Edited February 12, 2005 by Wolvereness

[jdickens]

Hi BabyG:

That is an ambitious project. It's kindof sad that AutoIt scripts can't be shared and appreciated by others (in general), because they are so specific. I made one I'm proud of that interacts with a lame inventory software we got married to here at work. Without that prog in the background, my script is pointless.

Note: as for the code in the include file that ran anytime the main prog ran, as you prob. know already, you might just throw that into a fn called "InitStuffX()" and then call InitStuffX() at the beginning of your main prog.

J

[Blue_Drache]

Hi BabyG:

That is an ambitious project.  It's kindof sad that AutoIt scripts can't be shared and appreciated by others (in general), because they are so specific.  I made one I'm proud of that interacts with a lame inventory software we got married to here at work.  Without that prog in the background, my script is pointless.

Note: as for the code in the include file that ran anytime the main prog ran, as you prob. know already, you might just throw that into a fn called "InitStuffX()" and then call InitStuffX() at the beginning of your main prog.

J

<{POST_SNAPBACK}>

You have just given me an excellent idea! My string manipulation routines just got better. Thank you!