Conditional includes

[lightwave]

Hey guys,

I apologise if this has been asked before. I have searched but couldn't find anything.

Is it possible to conditionally #include script files? I am building up a little library of things and I want to run them from one GUI where I select the task to run. However I don't REALLY want the script to pull ALL of the includes in when it's only running ONE task.

Is this something you can do with AutoIt? I'm pretty sure sticking include statements inside if statements doesn't work. Does anyone have any clever (or simple) suggestions?

Many thanks!!!

Al,

[Authenticity]

Edit: Mistake, if the include doesn't break the rules govern by the conditional structure then I guess it'd be valid to do something like:

#include-once

Global $avArray[50]
ConsoleWrite(UBound($avArray) & @LF)

Edited April 16, 2009 by Authenticity

[Mat]

Get someone who know what they're talking about to correct me on this but...

autoit comes across an if, it reads the statement until a then and if its true, carries on the line, and somehow know if there is an endif, and reads until then (unless there is an elseif or else keyword).

If you put an include somewhere thats not at the top of the script, as long as it's before the place where its used, its OK, so with out testing, i'm going to say its possible.

I've tested putting it in a simple loop, and it works.

however, when you compile you get problems... as it is no longer just an include, its the whole includes file copied into your script.

I don't know if it works putting an include inside function tags, didn't test that.

MDiesel

[Paulie]

Pretty sure it's not possible.

#include, like any lines that start with # are processed before the script is executed, if I recall correctly, the conditions wouldn't be considered until the files were already included.

You could, however create and additional script that parses your other script files and decides which includes you need.

Xenobiologist created an add-on for SciTE that does just that

Here

[Mat]

actually, have you tested that?

take a script that works and add this

if 1 = 2 then
include
endif

it WONT WORK!

Edited April 16, 2009 by mdiesel

[youknowwho4eva]

if 1 = 2 then

include

endif

Have you tried if 1 = 1?

The question is if you set that to a statement that at the time # are evaluated, that the script can not yet determine if it is true then will it work. Such as if you look for a file, if the file is found then include a script. If the # items are looked for first, the file search would not be performed so it would come up false even if the file actually exists.

Just going off what Paulie said, I haven't tested myself

[Mat]

The point I'm trying to make is if you put it in the statement, it DOES read the statement.

That answers the question, if it actually works is irrelevant. and you can include it as long as the place its needed is after (and I havent tested putting it within function tags.

Oh, and I have tested if 1 = 1. it worked too.

Edited April 16, 2009 by mdiesel

[Authenticity]

Try testing before assuming for nothing. ;-]

; ### .\include.au3 ###

#include-once
Global $MyVar = 50oÝ÷ ٩ݶjY^­«­¢+Øì±½°ÀÌØí5åQÍÑYÈôÌäìÌäìì½µµ¹ÐѼÍÑ¡¥É¹Ì¸()%%걃 Ìäí5åQÍÑYÈÌäì¤Q¡¸($¥¹±ÕÌäì¸ÀäÈí¥¹±Õ¹ÔÌÌäì)¹%()%%걃 Ìäí5åYÈÌäì¤Q¡¸
½¹Í½±]É¥Ñ ÀÌØí5åYȵÀì1¤oÝ÷ ØxÝý²z-n·)ජwb¶*'jZîë-éâ·l¥êßyËeÊö¥Õ¡jاr[yÚ±«&¢ËHOÜ¢jbêìv¬¶n¶Ø^~)^{hÊ«±Êâ¦Ö¬Ø¬JaDZjjez+"׫¦·­yÖ¬jëh×6; Global $MyTestVar = ''

If IsDeclared('MyTestVar') Then
    Global $MyVar = 50
EndIf

Or something similar...

[Valik]

You're confusing two separate issues. Conditional #include != conditional execution. The #include feature works unconditionally; it has to. Compiled scripts must have all the code available. Non-compiled scripts must behave as close as possible to compiled scripts so proper testing can be done. Thus, the idea that the file is conditionally #included is false. However, the code that's inserted in place of the file is conditionally executed.

So, since the file is not nor will it ever be conditionally #included, the idea is stupid. Write proper functions in the #include files, #include them at the top of the script like normal and call the functions like normal.

[reb]

Hey guys,

I apologise if this has been asked before. I have searched but couldn't find anything.

Is it possible to conditionally #include script files? I am building up a little library of things and I want to run them from one GUI where I select the task to run. However I don't REALLY want the script to pull ALL of the includes in when it's only running ONE task.

Is this something you can do with AutoIt? I'm pretty sure sticking include statements inside if statements doesn't work. Does anyone have any clever (or simple) suggestions?

Many thanks!!!

Al,

I ran across this item a few days ago.

Check this link.

http://www.autoitscript.com/forum/index.ph...c=93210&hl=

Hope this helps

REB

[Jos]

I ran across this item a few days ago.

Check this link.

http://www.autoitscript.com/forum/index.ph...c=93210&hl=

Hope this helps

REB

Obfuscator has the option to strip out all unused UDF's and Global Variables to limit the size of the output exe.

Not sure that is what the OP is after tho.

[MilesAhead]

You're confusing two separate issues. Conditional #include != conditional execution. The #include feature works unconditionally; it has to. Compiled scripts must have all the code available. Non-compiled scripts must behave as close as possible to compiled scripts so proper testing can be done. Thus, the idea that the file is conditionally #included is false. However, the code that's inserted in place of the file is conditionally executed.

So, since the file is not nor will it ever be conditionally #included, the idea is stupid. Write proper functions in the #include files, #include them at the top of the script like normal and call the functions like normal.

So how does one make a script that is backward compatible without conditional includes? For example, I'm just moving from 3.3.0.0 to AutoIt 3.3.4.0 and have to use OnAutoItExitRegister instead of OnAutoItExit to auto execute on close. But how do I screen it so that the same source doesn't generate an "undefined function OnAutoItExitRegister()" with the old version? It would be nice to just have a line of code such as:

OnAutoItExitRegister("OnAutoItExit")

that's only seen if @AutoItVersion is past a certain level. Seems like some sort of #if or #ifdefined equivalent must be around someplace?

Conditional includes and pragmas are quite common in C. Seems to be a mystery how to account for compiler versions here.

Edited March 3, 2010 by MilesAhead

[ProgAndy]

Seems to be a mystery how to account for compiler versions here.

Your script should always be compiled with the most recent vesion of AutoIt. Since AutoIt is free, you can expect from everyone to update.

(I do, I don't care for those not using the most recent STABLE version)

Edited March 4, 2010 by ProgAndy

[MilesAhead]

Your script should always be compiled with the most recent vesion of AutoIt. Since AutoIt is free, you can expect from everyone to update.

(I do, I don't care for those not using the most recent STABLE version)

I'm not concerned about the user. The compiled app is going to run on the machine. That's not the issue. The issue is I'd like to have one version of source code that will compile under both AutoIt3 releases. At least until some time goes by and I see the stuff that gets broken is minor and easily fixed. If something changes it may not be obvious instantly.

Seems like there should be a way to have one source file do the trick.

[MilesAhead]

I'm not concerned about the user. The compiled app is going to run on the machine. That's not the issue. The issue is I'd like to have one version of source code that will compile under both AutoIt3 releases. At least until some time goes by and I see the stuff that gets broken is minor and easily fixed. If something changes it may not be obvious instantly.

Seems like there should be a way to have one source file do the trick.

I'll say one thing for OnAutoItExitRegister() .. it makes it simpler to use _Singleton()

So I guess I'll have to like it even if I did drag my heels a bit.

[jchd]

I don't see any point in keeping sources compatible with obsolete and buggy previous versions. The picture is simple: either you stick with daddy's AutoIt syntax, semantics and bugs or you apply script-breaking changes and adapt your sources by using the newly-available advanced functions and then use the current version. Both 3.3.0.0 and 3.3.4.0 should be considered obsolete, just like all other releases below current version, 3.3.6.1.

For instance, OnAutoItExitRegister() makes life way simpler and stacking exit tasks using it works nicely in every situation. This was a big progress toward a more robust language context and I hardly see what makes you drag feet instead of adopting this baby heartfully.

There have been a large number of fixes and advances in UDFs too and it would be ... suboptimal to keep away of better supporting functions. Also current upgrade price is a bargain so don't miss the opportunity

[MilesAhead]

I don't see any point in keeping sources compatible with obsolete and buggy previous versions. The picture is simple: either you stick with daddy's AutoIt syntax, semantics and bugs or you apply script-breaking changes and adapt your sources by using the newly-available advanced functions and then use the current version. Both 3.3.0.0 and 3.3.4.0 should be considered obsolete, just like all other releases below current version, 3.3.6.1.

For instance, OnAutoItExitRegister() makes life way simpler and stacking exit tasks using it works nicely in every situation. This was a big progress toward a more robust language context and I hardly see what makes you drag feet instead of adopting this baby heartfully.

There have been a large number of fixes and advances in UDFs too and it would be ... suboptimal to keep away of better supporting functions. Also current upgrade price is a bargain so don't miss the opportunity

That's all fine if the new and improved version doesn't introduce bugs. OnAutoItExitRegister and _Singleton is an example. I assumed that _Singleton("idstring") at the top of the script would quit right then in the case of a 2nd instance. Apparently not so. The next line is OnAutoItExitRegister. Guess what? Even though the script supposedly "quit" since it's the 2nd instance, the exit function still registered. Here's the thing even weirder. The exit function saves some files on exit. Since no data was read in from the files, it overwrote the files with empty data. Now here's the thing. I move the call to OnAutoItExitRegister() to after the data files are read in... so even though I'm expecting the script to quit on the _Singleton() line, it continues, reads the data, until it encounters the OnAutoItExitRegister() call.

This may not be your daddy's oldsmobile, but it sure is confusing!!

[Richard Robertson]

That's all fine if the new and improved version doesn't introduce bugs. OnAutoItExitRegister and _Singleton is an example. I assumed that _Singleton("idstring") at the top of the script would quit right then in the case of a 2nd instance. Apparently not so. The next line is OnAutoItExitRegister. Guess what? Even though the script supposedly "quit" since it's the 2nd instance, the exit function still registered. Here's the thing even weirder. The exit function saves some files on exit. Since no data was read in from the files, it overwrote the files with empty data. Now here's the thing. I move the call to OnAutoItExitRegister() to after the data files are read in... so even though I'm expecting the script to quit on the _Singleton() line, it continues, reads the data, until it encounters the OnAutoItExitRegister() call.

This may not be your daddy's oldsmobile, but it sure is confusing!!

Then try learning logic and programming.

[MilesAhead]

Then try learning logic and programming.

Why don't you try making a comment that's not inane?

If _Singleton("idstring") is supposed to quit on that line

then why should the following OnAutoItExitRegister() have

behavior that varies depending on placement? It should never

be called in the 2nd instance.

If _Singleton("idstring") works some other way, please enlighten me.