Sign in to follow this  
Followers 0
lightwave

Conditional includes

19 posts in this topic

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,

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

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 by Authenticity

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

actually, have you tested that?

take a script that works and add this

if 1 = 2 then
include
endif

it WONT WORK!

Edited by mdiesel

Share this post


Link to post
Share on other sites

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


Giggity

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by mdiesel

Share this post


Link to post
Share on other sites

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-)ජ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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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


MEASURE TWICE - CUT ONCE

Share this post


Link to post
Share on other sites

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.


Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

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 by MilesAhead

Share this post


Link to post
Share on other sites

#13 ·  Posted (edited)

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 by ProgAndy

*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :(

Share this post


Link to post
Share on other sites

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 :(


This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Share this post


Link to post
Share on other sites

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 :idea:

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!!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

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  
Followers 0