mr_unreliable

After using autoit for a few years (on win98), when I installed v3.2.10.0 I got a "error loading file" when I tried to run a script from the scite editor. One puzzling aspect of this was that the script would run correctly from the (right-click) context menu. I found the fix for this in the general support forum. The fix involved setting up an initialization file which called for invoking autoit3a for the scite "go" command, rather than autoit3. However, one of the subsequent forum comments implied that you developers were planning to drop autoit3a in the near future. I would like to see you keep it available. Or failing that, then at least provide the source code that you are taking out -- so that I can put it back in to subsequent releases. You may think that anybody who sticks with a 10-year-old system doesn't deserve support (just like microsoft does). In my case, I was willing to go along, but the general advice one was hearing back when xp came out was "wait until all the security bugs are fixed" before you upgrade. And so, I waited. And waited. And waited. It seemed to me that the security bug patches never stopped coming. And so I never moved along to xp. Now we have vista. What I am hearing now is that the original release of vista is buggy, and one should wait until SR1 comes out in 1Q08. A number of corporations (if not most) are sticking with xp, and some system vendors are even responding with pre-loading xp on new systems instead of vista. For me, this is all beside the point. My ancient win98 system doesn't have the horsepower to run vista anyway (or xp for that matter). However, I am happy with win98 and will stick with it until my system dies. cheers, jw

This demo will display the day/date of the U.S. Holidays, for any year (that you input). Yes, there have been previous demos of the owc (Office Web Components) Spreadsheet control posted here, but most of them just demonstrated how to instantiate the control. This demo puts a little "meat" on them bare bones. The component used is OWC10.Spreadsheet, which comes with winXP (Office 2003) -- but it will also work with win98. If you don't happen to have that version, then you may download it from msdn. Or, you may also use a previous or later version (caution: the constant definitions have changed, going from OWC version 9 to OWC10). Acknowledgments: This shreadsheet was suggested on a page by "j-walk spreadsheet tips" http://j-walk.com/ss/excel/usertips/tip016.htm However, the link to the code page by j-walk was broken (ugh!), and so I had to reconstruct the page myself, using an XL spreadsheet which did the same calculations, courtesy of UNM(LosAlamos) CT202: http://www.la.unm.edu/~ostic/ct202/datafil...10/holidays.xls There are a few other "goodies" in the demo, but nothing spectacular. ashOWCSpreadsheetDemo.ZIP cheers, jw

I took from the fore-going comments that a comma could be used as a statement separator. When I tried that, I got the following diagnostic: "Error: Illegal text at the end of statement (one statement per line)." From that, I guess the conclusion is that there is no such provision for multiple statements per line, as one may find in other languages (e.g. vbScript). cheers, jw

hi folks, Is there a way to code multiple statements per line? Here is an example of what I am looking for: Dim $tElapsed : $tElapsed = 0 Where the semi-colon is used as a statement separator. cheers, jw

Yes, thanks, that did it, jw

hi gang, When specifying the msgbox flags in vb, it is recommended to use the "Or" operator to combine options, as in: vbInformation Or vbOK I tried this in au3 and it doesn't work: Const $vbOK = 0x0 Const $vbInformation = 0x40 MsgBox($vbInformation OR $vbOK, "Title", "Text") Adding the flags together DOES work (i.e., the "+" operator) MsgBox($vbInformation + $vbOK, "Title", "Text") Coming from vb, one would expect the "Or" and the "+" to produce the same result, but that is obviously not the case. please explain, jw

hi haravan, A minor point, but I am assuming that you wish to minimize your app to the TASKBAR, rather than the systray. I suggest that you use the show window minimize constant when you show your main window. Private Const SW_SHOWMINIMIZED = 2 Otherwise, if you really meant the systray (all those icons) there is other code to use. I suggest reading Steve McMahon's "Add your app to the systray the easy way". http://www.vbaccelerator.com/home/VB/Code/...Way/article.asp cheers, jw

sorry about posting vbScript code here, but it is easily converted to autoit. As the newer version of autoit can use com objects, it ought to be able to use "Shell.Automation". The point of this example is that it will use the same system capabilities as when you copy files using the system (context menu), and you will get the same system dialog with the progressbar and animation (that is, those pieces of paper flying through the air). One caution, with the system dialog, the copy operation must take long enough for the dialog to show and the animaton "to develop". Otherwise you won't see anything. ' script to demo shell.application Option Explicit Dim oSHApp ' as object Dim sSrc, sDest ' as string Const FOF_SIMPLEPROGRESS = 256 '(&H100) Set oSHApp = CreateObject("Shell.Application") sSrc = "c:\windows\temp\*.*" sDest = "A:\" ' use ms Animated Copy Applet, showing names and progressbar... oSHApp.Namespace(sDest).CopyHere sSrc ' use ms Animated Copy Applet, showing progressbar (but no names)... oSHApp.Namespace(sDest).CopyHere sSrc, FOF_SIMPLEPROGRESS Set oSHApp = nothing ' clean up WScript.Quit If you want to take this one level deeper, then you can use the system api directly. Go to msdn, and read up on the SHFileOperation api, and its associated SHFILEOPSTRUCT typedef. When you use the api, you get the same system dialog, progbar and animation you get with the Shell.App "CopyHere" method. Also the same caveat applies, if the copy doesn't take very long you won't ever see the dialog. But then, the only reason to show a progressbar anyway is to give users something to watch during a lengthy copy operation. cheers, jw

hi gang, I have read with interest the (new) COM capabilities of autoit3. As I understand it, the COM support is primarily oriented to interfacing with (running) COM objects, such as Excel, and with COM utilities, such as wscript.shell. This question is about one of the other uses of COM, that is as used in vb, where you make a reference to a (visual) COM object have it show up in your toolbox, and then drag it over and place it on your form (i.e., window). As I understand it, this can be done explicitly if the object has a "setParentWindow" type of function, where you can (via a COM interface) make the control a child window of the parent. But vb has something else. The drag capability is "implicit" and the connection is made with stuff I don't quite understand, but generally is referred to as "client site interfaces". That is, the control is "auto-magically" interfaced with the form (er, window). Does autoIt3 support this latter capability??? cheers, jw

I'm impressed "MHz". I tried it and it works. Did you have that one in inventory, or did you just write up 160 lines of code as a public service??? One of my concerns was that the "command.name.xx" numbers had to be sequential. But apparently not. My only suggestion would be to make a backup file before modifying the original. But then, I wasn't testing against the original file myself. Would that indicate a lack of total faith in your code? I decline to answer on the grounds that it may tend to incriminate me. cheers, jw

Thanks, I'll try it. cheers, jw

hi GR, I agree with "psalty" -- you don't need to re-invent the wheel. There are already many existing syntax-highlighting edit modules out there -- why not just use one of them, rather than writing your own. For one, there is "scintilla" (which is the basis for the scite text editor). you may fine scintilla here: http://scintilla.sourceforge.net/index.html There is another very competent code editor, named "Nathan's Code Sense" is highly recommended (by me). Unfortunately Nathan has closed down his website, but you may be able to find CodeSense on one of the omnibus download sites. cheers, jw

hi gang, I would like to simplify the SciTE tools and options menus. The reason is that I only have a 17in screen, and the menus are longer then my screen height, making navigation somewhat cumbersome. On the tools menu, there are a number of autoit tools included that I am probably not going to use, at least for a while until I get to be more proficient. I can see these "tools" spelled out as "command" parameters in the au3.properties file. I can imagine that I could rebuild the au3.properties file to suit my purposes, but that means re-building for each new release. Is there an easier way? What I would like to see is a way to modify the SciTEUser.properties file, to change the tools menu, keeping some tools and elimination others. That way, I only have to worry about changing ONE properties file for each new release. Moving on, there is also the "options" menu, which includes menu items for a (great) number of languages, most of which I don't use. I found the listing of the languages in the SciTEGlobal.properties file, and "commented-out" the languages that I don't use. Considering that involves yet another file that I don't wish to modify for every new release -- my question is: is there any way to make those changes in the SciTEUser.properies file. That is, can one take out those languages listed in the "options" menu via the SciTEUser.props file? Thanks in advance for any help, jw

hi Gerome, You seem to be promoting your own scripting language (FBSL) on a forum devoted to AutoIt3. As best I can tell, except for the lack of class code in AutoIt3, the two languages are pretty much fuctionally equivalent. Could you take some time and comment on the following? 1. What was your motivation in writing FBSL. Were you looking for something different? Did you hope to surpass AutoIt3? 2. Why would somebody want to switch from AutoIt3 to FBSL? 3. What do YOU think are the advantages of FBSL vis-a-vis AutoIt3? 4. What are your plans for the future, if any? That is, where do you plan to take future development of FBSL? cheers, jw

Generally, this forum is for code, but I am posting something different -- a color scheme for the SciTE syntax coloration. This was motivated by my preference to avoid staring at a "glaring white" background all day, in my text editors. This preference probably can be traced back to the days of WordPerfect 5.1, where the text was presented as white on blue background (you have to be ready for retirement, if you remember that). Anyway, this color scheme has various colors, shown on a "dark teal" background. Try it, you might like it. cheers, jw myColorScheme.txt

I am looking to customize SciTE, more specifically to eliminate a number of menu options that I won't be using. I can see how to do this by modifying the SciTE configuration files, by simply "commenting-out" the menu items. I tried that and it worked. But then, I read that one shouldn't mess with the SciTE config files, If one wishes to customize, one should place _ALL_ customizations in the SciteUser.Properties. So here is the question, how do you eliminate a menu item from the SciteUser.Properties file??? Another question: I would like to hide the "Fold Margin". I am able to do this via the menu (click view => foldmargin). But I can't seem to do it via the SciteUser.Properties file. I tried this: fold.margin.visible=0 but, that has no effect. tiafah, jw

I noticed an extremely brief mention of Plugins in the beta doc. Then I searched here, and found some discussion, and a couple of actual plugins offered. There was also some discussion about why anybody would need a plugin, as long as one could DLLCall a dll entry point. There was also mention that (maybe someday - but not now) a plugin would be better than an external dll, as it would be incorporated within the exe, thus making distribution easier. I also found and downloaded the "plugin SDK". Still, I'm not satisfied. I couldn't find any description about what a plugin (for autoit) should be, how it should be written, why one would use a plugin instead of an ocx, etc. As best I could surmise, if you liked to code in c++, and you wished to have some feature that was/is currently missing from autoit, then a plugin would be your weapon of choice. Is that correct??? Also, I noted that the plugins which were offered here didn't come with any source code. Is this acceptable to the autoit community? Over in the wsh/vbs world, people are extremely sensitive about utilities which are offered without source. More specifically, they are concerned about malicious code being inserted into their systems by "black box" type code (i.e., compiled/binary code where you don't know what's going on under-the-covers, an ideal situation for concealing malware). cheers, jw

My browser could not follow the link above, and so here is another reply. Sorry if it duplicates already available material. There is a vbs script attached which does what you want. It will copy some files to a diskette, using the "shell.application" object, and will show a progress dialog. NOTA BENE: the underlying api apparently does not show the progress dialog for short file copies. So if you use it for a small file, the file will get copied, but no dialog will be shown. That is the reason that the demo script is copying to a diskette -- diskettes are always slow. There is a second attachment, with is just the vbs script converted to autoIt (requires the beta version). Finally, if you really have a taste for the "real geek" stuff, then take a look at the SHFileOperation API function, with its accompanying SHFILEOPSTRUCT typedef. That api is what "shell.application" uses, and the api code is what is showing the filecopy progress dialog. If you look up the api, you will find that it has four basic functions, move, copy, rename and delete. plus a number of options too numerous to repeat. Here is a link to SHFileOperation documentation: http://msdn.microsoft.com/library/default....leoperation.asp cheers, jw p.s. the attachments have a "txt" extension, because of the propensity of some AV apps to deny vbs downloads. testShellAppCopy.vbs.txt testShellAppCopy.au3.txt

just in case anybody else is curious, the answer to my problem was to use the: "_GUICtrlListAddItem" function found in the: #Include <GuiList.au3> file (part of the beta distribution). The listadditem function does _not_ look for any duplicate item among the previously posted items, as setdata does. cheers, jw

hi gang, As you know, if you add an item to the list control which is the same as an existing item, the list control will (both) fail to add that item, and will highlight the previous identical item. I happen to be using the list control for debugging messages, a situation where some of the debug messages are identical to some previous debug messages -- and the characteristic of failing to post the message plus highlighting some previous message is defeating my purpose. Two (er no, three) questions: 1. does autoit provide a means of "turning off" the behavior mentioned above? 2. failing that, is there any other way (for example resetting the style bits) that will cause autoit to leave my postings alone. 3. failing that, suppose I create my own listbox, using the create window api call. Will autoit STILL do the search for an identical item, or will autoit tend to ignore any "user created" controls? thanks in advance for any help, jw

Some interesting code found posted here requires the inclusion of mem.au3, bin.au3 and mem.dll. I am assuming that these utilities are available for downloading, but have been unable to locate a link. The autoit forum search engine doesn't find them (i.e., there are plenty of references to those include files, but not any links to the downloads), and in a larger context, neither does google. Can anybody here can give me a clue? cheers, jw

hi gang, In vb, if you wish to obtain the memory address of a variable, you can use the VarPtr function. Yes, yes, I do know that autoit doesn't have a varptr function, but it DOES have dllcall. The "api-way" to get the memory address of a variable is this: Declare Function VarPtr Lib "msvbvm50.dll" (ByRef Var As Any) As Long I can't see how to convert this to dllcall. As I understand it, it has to be "ByRef" because you want to get the actual address of the parameter, not the address of a copy of the parameter (i.e., "ByVal"). any help would be appreciated, jw p.s. if you are tempted to "flame" me for wishing to deal with absolute memory addresses, kindly stifle yourself. Although you may not agree, there are legit reasons for doing this.

The "Validate_DateTimeLocalFormat()" function is intended to check whether a date+time string is valid IN THE CONTEXT OF THE "LOCALE" FORMAT, i.e., the format used in your country (or even some format peculiar to your own organization or application). There is a "_DateIsValid" function in the "date.au3" include file, which checks a date+time string for conformance with an ISO standard. If you are NOT conforming to that ISO standard, but rather are using some local standard like the one sometimes used in the U.S. (i.e., mm/dd/yy hh:mm:ss xM), then this function is for you. Also note, this function is using the vbScript "RegExp" (regular expression) object, rather than a "brute force" approach (i.e., character-by-character testing), to validate the string. Yes, yes, I do know that autoit has its own regexp function. I was just experimenting with the feasibility of using "external objects" in autoit code (in this case a vbs object). And it worked, sort of. While this function may be expanded through the use of regexp pattern matching, as coded it will only test for one local variation, that is a proper U.S. datetime format... cheers, jw auiIsDateTimeValid_wRegExp.au3 mru.ico

hi gang, I would like to pick out a specific item from a collection. I tried the emum items capability and it works fine, i.e., For $Match In $Matches ; (for each) loop through the $Matches collection ... Next To go one step further, in vbScript, it is possible to pick out an individual item like this: $Matches(1).Value That is vbs shorthand for specifying a specific item like this: $Matches.Item(1).Value Both of these syntaxes work in vbs, but I couldn't get either to work in au3b. Note: I also tried square brackets, which didn't work either. Am I missing something, or is it not possible to address an individual item in a collection??? tiafah, jw

The "_DateTimeFormat()" function (as found in the date.au3 include file) expects to find the date/time locale-format-related info in the registry. Apparently this is true if one is using nt or xp. It is not true for a win9x system, (or, at least not _my_ win0x system). There are vb source code sites that address this issue (for example, Randy Birch), and which assert that to get those constants for ANY system, one must make use of the "GetLocaleInfo" api. The code attached to this posting, shows the "_DateTimeFormat()" function converted from using the registry to using that api, just in case there are any other win9x users out there. I encountered one other "sticky wicket". Once I had the "_DateTimeFormat()" working for me, it is producing a result like this: "mm/dd/yy hh:mm:ss am/pm" -- which is appropriate for the U.S.A. However, the authors of the "_DateIsValid()" function are apparently Euro-centric, in that my "mm/dd/yy hh:mm:ss am/pm" was declared to be invalid. The only acceptable format for the "_DateIsValid()" function is this: "yyyy/mm/dd[ hh:mm[:ss]]". Perhaps I need to work on an "IsDateValid_ForYourLocale()" function, which would be more accepting of the date/time format commonly used in the U.S.A. cheers, jw win9x_DateTimeFormat.au3