TheDcoder

Isn't Redis open-source? How can it be a proprietary datastore if it is free software

@tbodine88 Since you are already using SciTE to tidy the code, you can also change the encoding to UTF-8 or local code page before saving

@TheSaint I don't see why it is incorrect. For programs which can handle multiple copies (separate instances running in different locations/folders), it is useful to limit to only that particular executable file, if the program had a single constant string for singleton that would obviously not work. Take my program ProxAllium for example, you can have 2 copies of it and have them run simultaneously, but it will warn you if you try to start another instance of the same copy. So it is would be wrong to strictly say "the string for singleton must be unique for the script", your script should be able to supply unique strings according to the conflict conditions. (like the path of the script in ProxAllium's case) Of course you could still go the easy way and just use a hardcoded string, but that doesn't make my usage incorrect

It doesn't have to be, you can also choose to deliberately generate a string according to whatever set of rules you want for you want. A good example is my code which uses the full path of the script, it is designed to be totally portable and conflict free from other instances of the program excluding the it's own executable

@Carm01 The example fails because the FTP server used in it no longer exist. Also you are attempting to use the URI of the directory as the hostname for the server, it won't work. Try this: #include <Array.au3> #include <FTPEx.au3> Local $sServer = 'ftp.adobe.com' Local $sUsername = '' Local $sPass = '' Local $hOpen = _FTP_Open('MyFTP Control') Local $hConn = _FTP_Connect($hOpen, $sServer, $sUsername, $sPass) _FTP_DirSetCurrent($hConn, "pub/adobe") ; Set the directory Local $aFolders = _FTP_ListToArray($hConn, 1) _ArrayDisplay($aFolders) Local $iFtpc = _FTP_Close($hConn) Local $iFtpo = _FTP_Close($hOpen) Note the usage of _FTP_DirSetCurrent to change the current working directory on the FTP server

@ur Good to see that it is working, I use @ScriptFullPath because it is kind of good and unique identifier, though you should be aware that you can run multiple instances of the same script but a different copy of it in a different location if you use my method. The string parameter is totally arbitrary and you can have it as anything you want.

You can also try using the full path of your script for singleton as the identifier, here is an example from one of my projects: Handle_MultipleInstance() Func Handle_MultipleInstance() If _Singleton(StringReplace(@ScriptFullPath, '\', '/'), 1) = 0 Then Local $iMsgBoxParams = $MB_ICONWARNING + $MB_YESNO + $MB_DEFBUTTON2 Local $sMsgBoxMsg = "ProxAllium seems to be already running, do you still want to create a new instance?" Local $iUserChoice = MsgBox($iMsgBoxParams, "ProxAllium is already running!", $sMsgBoxMsg) If $iUserChoice = $IDYES Then Return Exit EndIf EndFunc Feel free to adapt it as you wish

Try using _FTP_ListToArray and it's associated functions to get the list of files and folders

@Fractured My pleasure I normally totally disregard the actual ID beside storing it inside a well-named variable, you can think of the variable as the name of the control. That is how I worked my way up in the beginning. Just my two cents Feel free to post about what you are trying to do and maybe some of us can offer suggestions.

No, it is not possible as far as I know. They are internally generated and managed by AutoIt for each control. Only way to change them is to destroy the control

@KaFu Great, thanks! An update after two years! I was actually very inspired by your program. I researched many months about a similar solution for linux, in the end I even decided to write my own tool... after many months of (trying to) learning a bunch of languages and failing, I finally made myself a similar tool which can hide windows using C. It should work on any linux computer which uses the X display server, it is called mapmywindows and it is open source. I started working on it in March this year, but it was just a proof of concept until recently (a few days ago) I implemented full keyboard shortcut support and ability to hide multiple windows. Quite a coincidence Sorry for taking over your thread, I got excited. Thank you for the work and inspiring me P.S Also sorry for stealing the name... LOL

@water Can't say I disagree, thanks for the work

I agree that there is a need of a good example as quite a bit of Excel COM is involved, usually it is hard to find documentation for COM compared to finding documentation in AutoIt UDFs...

@apiznse I would like to address the fact that you are not responsible for any abnormal behaviour caused by modification of your INI files, the responsibility should be fully on the "operator" who works on the manufacturing system. It really isn't possible to "secure" your software from being modified when the computer is not in your control So I would recommend educating the operators and transfer the responsibility to them, Ideally they wouldn't need a software to baby sit them if they are working on a manufacturing system. If you still insist on somehow dettering or discouraging this behaviour, you should try @AutoBert's solution of removing these options from the production version... but if you don't want to even do that, then I'd recommend applying some kind of encryption/obfuscation as suggested by @TheSaint. You have to remember that you cannot fully make sure that they don't change anything which can modify the behaviour, the user is responsible for what the software does, not the developer!

@diehardfans Also GUIGetMsg is only useful if you have an active GUI created by the script, else use Sleep(10) like it has be said many times previously in this thread

There isn't really a direct way for other browsers, but i recall someone made an UDF for Firefox (doubt it would work latest versions of Firefox though). You can also try UIAutomation which is a more generic way:

IE stands for Internet Explorer, and IE.au3 only works with Internet Explorer... not sure how and why you are trying to use it with a different browser?

My pleasure bud... along with the angst part This will definitley be useful, hopefully I will get a chance to use your UDF soon

@careca I see your point, I don't see why @ScriptName cannot be supported if @ScriptFullPath already is. But you can easily work around this by using @ScriptFullPath in the first parameter and @ScriptName in the second parameters since it does allow variable expressions Local $InstallDir = @LocalAppDataDir & '\123' FileInstall(@ScriptFullPath, $InstallDir & "\"&@ScriptName, 1)

SQL isn't exactly a replacement for INI but it will do for INI databases that you frequently use LOL

@careca I think you are experiencing the X Y problem... You want to do X but you are asking about Y which can help you do X, let us know what X is so we can directly help you with it. You cannot use expressions/variables in the first parameters, but you can use relative paths that are relative to the current script . ; Example FileInstall("config.ini", @ScriptDir)

Wow... an assumption, you never mentioned that you were using _FileCreate to zero it's contents I beg to differ, I only suggested FileOpen to create or empty the file, you need not to use it for Ini functions. I went the extra mile to show you how _FileCreate could be replaced in such a way that it never produces a BOM: ; Drop in replacement for _FileCreate Func _FileCreateNoBOM($sFilePath) Local $hFile = FileOpen($sFilePath, $FO_OVERWRITE + $FO_UTF8_NOBOM) FileClose($hFile) EndFunc Another surprise: The _FileCreate function also uses FileOpen, have a look at it yourself in File.au3 include

_FileCreate might be the culprit, IniWrite if it is written correctly (and I think it is) then it should be automatically be able to handle new file create with the appropriate encoding. I'd recommend going the FileOpen route to create a new file... or even better just use IniWrite while being file agnostic in all situations, it should handle file creation. That is correct, like I have said above, use IniWrite for best results. But FileOpen is also a better alternative when used with appropriate flags: Sorry, I mis-remembered the function and flag names in IRC, please refer to my post for the correct names

Looks like @careca has beat me to it, I examined both the good and bad ini files in a hex editor to look at the raw bytes inside the file. Surprise surprise, the bad file has a byte ordering mark (BOM) at the start of the file (EF BB BF)... this is missing in the good file. It is a common practice to use the BOM to assist programs in identifying the encoding correctly, but unfortunately it has side-effects if the file isn't identified correctly. I reckon it is a classic case of an encoding mis-interpertation with the Ini functions in AutoIt. it is probably best to use FileOpen with the $FO_UTF8_NOBOM flag to create a file without the (probably) offending BOM character. Also I would like to mention again that I have not confirmed anything but the glaring difference both the files have. I am running Linux at the moment and cannot test anything.

@milkmoron Yes, just open the included wrapper script and and look at the functions . Pro Tip: If you have full SciTE4AutoIt3 installed then you can use Alt + Q to open SciTE Jump which lists all of the functions!