lightwave Posted April 16, 2009 Share Posted April 16, 2009 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, Link to comment Share on other sites More sharing options...
Authenticity Posted April 16, 2009 Share Posted April 16, 2009 (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 April 16, 2009 by Authenticity Link to comment Share on other sites More sharing options...
Mat Posted April 16, 2009 Share Posted April 16, 2009 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 AutoIt Project Listing Link to comment Share on other sites More sharing options...
Paulie Posted April 16, 2009 Share Posted April 16, 2009 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 thatHere Link to comment Share on other sites More sharing options...
Mat Posted April 16, 2009 Share Posted April 16, 2009 (edited) 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 AutoIt Project Listing Link to comment Share on other sites More sharing options...
youknowwho4eva Posted April 16, 2009 Share Posted April 16, 2009 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 Link to comment Share on other sites More sharing options...
Mat Posted April 16, 2009 Share Posted April 16, 2009 (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 April 16, 2009 by mdiesel AutoIt Project Listing Link to comment Share on other sites More sharing options...
Authenticity Posted April 16, 2009 Share Posted April 16, 2009 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... Link to comment Share on other sites More sharing options...
Valik Posted April 16, 2009 Share Posted April 16, 2009 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. Link to comment Share on other sites More sharing options...
reb Posted April 16, 2009 Share Posted April 16, 2009 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 helpsREB MEASURE TWICE - CUT ONCE Link to comment Share on other sites More sharing options...
Developers Jos Posted April 16, 2009 Developers Share Posted April 16, 2009 I ran across this item a few days ago.Check this link.http://www.autoitscript.com/forum/index.ph...c=93210&hl=Hope this helpsREBObfuscator 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. SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
MilesAhead Posted March 3, 2010 Share Posted March 3, 2010 (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 March 3, 2010 by MilesAhead My Freeware Page Link to comment Share on other sites More sharing options...
ProgAndy Posted March 4, 2010 Share Posted March 4, 2010 (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 March 4, 2010 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 Link to comment Share on other sites More sharing options...
MilesAhead Posted March 4, 2010 Share Posted March 4, 2010 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. My Freeware Page Link to comment Share on other sites More sharing options...
MilesAhead Posted April 17, 2010 Share Posted April 17, 2010 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. My Freeware Page Link to comment Share on other sites More sharing options...
jchd Posted April 17, 2010 Share Posted April 17, 2010 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 hereRegExp tutorial: enough to get startedPCRE 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) Link to comment Share on other sites More sharing options...
MilesAhead Posted April 24, 2010 Share Posted April 24, 2010 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!! My Freeware Page Link to comment Share on other sites More sharing options...
Richard Robertson Posted April 24, 2010 Share Posted April 24, 2010 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. Link to comment Share on other sites More sharing options...
MilesAhead Posted April 24, 2010 Share Posted April 24, 2010 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 linethen why should the following OnAutoItExitRegister() havebehavior that varies depending on placement? It should neverbe called in the 2nd instance.If _Singleton("idstring") works some other way, please enlighten me. My Freeware Page Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now