2Radon

Does that mean there are actually better IDEs than VS for C/C++ because of that? Or the other features still make it superior?

Sorry if this might be out of place entirely. Like this. Why does it exist for C# in Visual Studio 2013 but not for C/C++? In Visual Studio 2013 I see something like this for functions and stuff. Which I cant even find here in MSDN: http://msdn.microsoft.com/query/dev12.query?appId=Dev12IDEF1&l=EN-US&k=k(printf);k(DevLang-C%2B%2B);k(TargetOS-Windows)&rd=true I am just a beginner, but this tooltip does seem rather useless..? Or can I set up to see something like in SciTE? Also, I wonder if it can show a list of my variables like in SciTE when I write their name.

Alright, let it be in Developer Chat then. Hope guys got some advice. :s

For Windows, and not sure but maybe Linux as well... It would also include sort of customizable 'widgets' on screen, opening multiple programs and keeping them idle, quick execution of several programs, hiding windows of other programs, etc. Basically, maybe you could call it application manipulation... So, as I am starting to dig into the C lineage to gain broad knowledge (before also tackling Java) after basic studies in other languages at school and creating a minor version of this project in AutoIt over several months while in internship, I ask your advice to elaborate which language you know will accomplish this and more in the best way. Am I thinking right that here 'the best' doesn't mean just performance, but also how much coding and readability it would take?

And how can I do something like that?

Thanks, that worked! But can logging or tracing be done without making the code of the program look cluttered like a top-tier mess? Sure, I can add and remove them at will, but is that how it is properly done? So if I want to keep adding the trace lines continually over a long period of time as people use my program I suppose I make it somehow display time and date besides the line..? Tracing is one thing, but another is logging - how does a dude do that in a similar output fashion?

I have to do it without SciTE. Users won't have that. Does the console happen even without SciTE, and then it can be sent to a txt file after all?

MsgBox? I mean, write log to txt file.

I'd like the logging to always happen for every user and output it to a text file so I can pick it up and use to improve/fix. If I add trace lines, it will only be visible in SciTE? The Debugger, is an external program, right? Can't have the user using something like that..

I am looking all around for how to log everything that my program does so I can see what was successful, what was not, what it did, what it returned, what went wrong, etc. I've tried some ways to log, but nothing at all worked anything like that. Same for an error function. It just sits in my program and does nothing. But for now I am asking how do I make my program write its activity in a text file.

So that means every other program in the world uses a BAT file to create these directories and files? Because I have to.

I have one script, then 6 more scripts in a directory next to that main script and I now have to compile them all one by one and increment their versions for each of them manually and create the folders manually which all takes a few minutes before it is ready to work. I also think I shouldn't track each scripts version separately when I modify them, instead calling them all one version since it is one program, or should I? Is there a way to ease this process and make it more efficient?

This is so freaking frustrating. Can't start testing. Why should I not put ini files in program directory? I want them to be in Appdata. Maybe I should use CMD in my script to try create it?

Impractical... :s What is wrong about $fINI = @AppDataDir & "ProgramMain.ini" and IniWrite($fINI, "General", "Boot", 1) ? I can confirm it works with other directories. This has got to be something about the -sometimes- restriction to write on C: like in Program Files and whatnot. EDIT: This is my script: IniWrite(@AppDataDir & "\Program\Main.ini", "One", "User", "Dude") Because I just wrote this whole line in a new script file and it doesn't work.

It did not. That can't be an option anyway because I can't have the users click Yes every time for admin as this has to happen automatically so they don't have to be at the PC.

While I was writing my program, it worked fine. All IniWrites and everything worked and created ini files and everything I asked in @AppDataDir. But suddenly, without anything related to that changing, it is unable to create any file in @AppDataDir. It will write to an ini file in @AppDataDir if I manually create it there, but using AutoIt I can't create it. Nothing happens there.

Two days of messing with it and testing I can't presume anything other than random.

So can you come up with why exactly my code makes flawed results like it does? Is it AutoIT related, not really a fault in my code per se?

Dangit, things I didn't really expect appear in UDFs! But regarding my own pile of code - why does it do so? Can I make it work without digging into this UDF? Does double-encryption like I am doing help any actually? I want to hide the fact that it is an ini file also, like I am doing.

Attached a new code I made. This one works better though, but still, when I mess around with deleting and writing and other things I can do with this it ends up in about the same glitch. Play around with this and see that it doesn't work as intended: Creds and Creds.ini are hidden files. Use WriteCreds.au3 to write to Creds.ini and then encrypt to Creds. Use ReadCredsTest.au3 to see what it can read out of Creds (not Creds.ini). Using WriteCreds GUI, delete some, write some again, overwrite some, check inside Creds.ini and what ReadCredsTest.au3 says. Gosh! CredsSolving.zip CredsSolving.zip

I want to give the program for you guys to see and find the problem, but it's got sensitive information for a company, some names, which could be really messy to cover. I am still constantly testing it all day and it is just senseless. The code I wrote in the first post is, I think, responsible for writing only ONE section + USR and PW key in the file that is double encrypted. Could double encryption mess it hard? It encrypts the ini value, which is written in the ini, and this ini file is encrypted. To retrieve the PW and USR it is done vice versa. But It won't write more than one section, no matter that it is different. Also, a bit earlier it worked by saving 2 sections and not saving 2 others. Now it's back at one. No idea. I read the code through several times, it is supposed to do what I want, everything matches from A to Z, but it doesn't. I don't see it. Can I maybe log whatever the program does very closely and see where it writes in the file and what happens then, and what happens in encryption steps? Shouldn't this successfully Decrypt the file, delete the said lines and then encrypt this modified file back to the previous file? If FileExists($fCreds) Then _Crypt_Startup() _Crypt_DecryptFile($fCreds, $fCredsINI, "AteaReady4PonyLimbo", $CALG_AES_256) ; Turn it back into an ini file FileSetAttrib($fCredsINI, "+H") IniDelete("Creds.ini", $rCredsButton);, "USR") IniDelete("Creds.ini", $rCredsButton);, "PW") ;IniWrite($fCredsINI, $rCredsButton, "USR", "0") ; Doesn't work as well ;IniWrite($fCredsINI, $rCredsButton, "PW", "0") _Crypt_EncryptFile($fCredsINI, $fCreds, "AteaReady4PonyLimbo", $CALG_AES_256) ; Turn the ini back into an encrypted file _Crypt_Shutdown() FileSetAttrib($fCreds, "+H") FileDelete($fCredsINI) ; Delete the ini so that only a double-encrypted credentials file remains

Nop, I simply replaced sensitive information as I was writing this post. In my real code it has everything and works but as I described weirdly behaves I believe...

Sorry, should have cropped that too. That is a different ini file. This is the most important part: _Crypt_Startup() $rUSR = _StringEncrypt(1, $rUSR, "cryptpw") ; 2 ARPL $rPW = _StringEncrypt(1, $rPW, "cryptpw") ; Encrypt the string If FileExists("Creds") Then ; If a file containing credentials doesn't already exist _Crypt_DecryptFile("Creds", "Creds.ini", "cryptpw2, $CALG_AES_256) ; Turn it back into an ini file FileSetAttrib("Creds.ini", "+H") EndIf IniWrite("Creds.ini", $rCredsButton, "USR", $rUSR) ; Add the encrypted USR and PW values under the chosen section IniWrite("Creds.ini", $rCredsButton, "PW", $rPW) _Crypt_EncryptFile("Creds.ini", "Creds", "cryptpw2, $CALG_AES_256) ; Turn the ini back into an encrypted file _Crypt_Shutdown() It currently saves 2 out of 4 different sections for some friggin flippin dog knows what reason and drives me mad and keeps me tied.

Nay, as stated in the help file for IniWrite(), first comes file, then section, then key, then value. Just like I have.

Seems I have found out through testing that when decrypting it somehow brings back only one Section of the ini file. What am I fusing here?!