save the value of an edit object in a dialog

esuohlluf · Post by **esuohlluf** » Sun Apr 02, 2006 9:22 am

Is it possible to save a text string entered into an edit object, within the script itself , (without using a file), for this value to remain after the script
or exe is closed?

Bob Hansen · Post by **Bob Hansen** » Sun Apr 02, 2006 11:41 pm

Not within the script, but could write to registry.

But that would violate your spec of not using a file, so I guess that would not be acceptable.

JRL · Post by **JRL** » Mon Apr 03, 2006 3:40 pm

There is always ouroboros.

You could have a script that deletes then rewrites itself with the new information embedded within.

Something like this:

///Text that is saved
Let>savetest=Text to test

///Path to Macro Scheduler
///My scripts and msched.exe happen to all be in the same folder
///Your setup may require %path% to be different
Let>path=C:\Program Files\MJT Net Ltd\Macro Scheduler\

Dialog>Dialog1
Caption=Information Rewrite Test
Width=230
Height=160
Top=CENTER
Left=CENTER
Close=0
Label=Test Information,70,15
Button=OK,75,85,75,25,3
Edit=msEdit1,15,30,200,%savetest%
EndDialog>Dialog1

show>Dialog1,r

///Unneccesary line to demo what is to happen
mdl>Old info was: %savetest%%CRLF%New info is: %Dialog1.msEdit1%

///Read the current script to a variable
ReadFile>%path%Save to self test.scp,OldScript

///Replace the old text with the new text in the current script variable
StringReplace>OldScript,Let>savetest=%savetest%,Let>savetest=%Dialog1.msEdit1%,NewScript

///If the script has been aborted its possible the temporary script file might exist
///Better to be safe and delete it than add on to it and mess up the works
IfFileExists>%path%Save to self temp.scp
DeleteFile>%path%Save to self temp.scp
EndIF

///Prevent writeln from adding a carriage return, otherwisw the script will
///get one blank line longer each time it is run
Let>WLN_NOCRLF=1

///Create a temp file from the current script variable with the replaced text
WriteLn>%path%Save to self temp.scp,wresult,NewScript

///Delete the running script
DeleteFile>%path%Save to self test.scp

///Rename the temp file to the running script
Let>MF_RENAME=1
MoveFile>%path%Save to self temp.scp,%path%Save to self test.scp

Hope this is helpful,
Dick

esuohlluf · Post by **esuohlluf** » Tue Apr 04, 2006 9:07 am

Thank you

I have a script that reads users and passwords from an excel file and
as an improvement I was looking for a method to add,edit and store the
users and passwords within the script using a dialog so that the script
was self-contained.

As a beginner it will take me some time to digest your script and adapt it
into mine. It may be a little out of reach for me right now., but I'm sure to gain knowledge reviewing it.

Bob's suggestion for an ini file seems to fit my purpose of eliminating the
need to open excel to store each change or add. The ini file will give me the ability to save variables that store for example which user/password were used last, in a way that should be much cleaner than using a spreadsheet.

I have never used an ini file and am trying to learn how to use them. I posted a question on ini files under a new topic and would appreciate
your help.

pgriffin · Post by **pgriffin** » Tue Apr 04, 2006 2:30 pm

I may be making this far too simple, but to answer the original question, couldn't you copy a variable (or multiple variables concatenated) to the clipboard?

As you read variables from Excel

dderequest> read it into some var
Putclipboard> to put this var into the clipboard

if you need all vars in the clipboard, just add

let>AllVars=
concat>AllVars,ExcelVar
concat>AllVars,; (separate the vars with a semicolon, if you like)
PutClipBoard> to put the entire string of vars in the clipboard.

Your original question was just that you want variables to exist after the script or exe has stopped running...

esuohlluf · Post by **esuohlluf** » Tue Apr 04, 2006 4:41 pm

What i was hoping to do was create variables (ex: passwords) through
a dialog and save them within the script eliminating the need to interact
with excel.

This would make the exe more transportable to another computer, plus
it would save as the variables are created. If I were to use excel I would
need to open excel for each event or have it left open to do that. And if I were to save to excel at the closing of the exe the entries would be lost if there was an unexpected shutdown.

JRL's solution would achieve that, but at my experience level it would be difficult to impliment into my script, I'm still trying to get a complete
handle of his script.

The solution Bob mentioned seems like it might be within my grasp and would be an improvement over using Excel once I gain a basic understanding of how to use ini files.

JRL · Post by **JRL** » Tue Apr 04, 2006 4:56 pm

Maybe save you some time and headache.

The "solution" I posted earlier will not work with an executable file, it will only work with a script. The reason it can work with a script is that scripts are text files. So, to make this portable each computer would need to be running Macro Scheduler.

Later,
Dick

pgriffin · Post by **pgriffin** » Tue Apr 04, 2006 6:03 pm

Just my opinion, but having code for a couple decades, I would suggest not storing data of any kind in a program.

If you are uncomfortable with Excel, then why not store them a .mdb format (MS Access). it is very simple to read and write .mdb's with MacroScheduler.

Just search the forum or visit the VBResources link on the Support tab, or any one of us can send you code examples.

Paul

Bob Hansen · Post by **Bob Hansen** » Tue Apr 04, 2006 8:48 pm

A problem with my suggestion of using INI files is that they also are open to snooping, just like Excel, and the registry has the same hole.

But.....how about using Macro Scheduler's Encryption? Check out the help for Encryption.

This would allow you to do some hard coding of names/passwords, but keep them out of sight without proper password authority for access.

-------------------------------------
If you want to stay with INI, then you could name it something other than *.INI, and don't make the section labels obvious like "username" and "password". Use words like "system kernel" and "skg_prts" so that even if one is browsing files, this will not be so obvious.

And add some additional bogus section values to further hide the real values from snooping eyes.

And/or, add a prefix and/or suffix to values when creating them and parse them out on retrieval.
---------------------------------------
Oh yes, you can also put the INI file in a hidden out of the way folder and make the INI file hidden also.

esuohlluf · Post by **esuohlluf** » Tue Apr 04, 2006 9:09 pm

Thank you all of this information is helpful

esuohlluf · Post by **esuohlluf** » Tue Apr 04, 2006 9:15 pm

I am not uncomfortable with excel.
I had a working script with excel before I made the post.
I was just seeking a better solution than using excel.

JRL · Post by **JRL** » Tue Apr 04, 2006 9:29 pm

I concurr with everything Bob said. I like to name my "hidden" INI files with a DLL extension. Even experienced snoopers pass them by. Just restrain the impulse to store them in the Windows System directory. They'd be well camoflaged there but subject to overwrite if an installation happened to use the same file name.

I'm currently working on putting logon names and passwords into an INI (DLL) file that will reside on a network server in plain site of all on the network. That was the reason for creating the encryption tool I posted yesterday. The likelyhood of someone opening a file named .DLL with a text editor is slim, especially since I've buried it in with 250,000 files and 30,000 directories. But should that occur, the passwords will all be encrypted.

I also agree with Paul. There are not many situations I can imagine, where you would want your data stored in the program. That said, I can imagine a few.

Later,
Dick

esuohlluf · Post by **esuohlluf** » Mon Apr 10, 2006 12:03 am

Are you saying that I should name the file *.dll.ini ?

JRL · Post by **JRL** » Mon Apr 10, 2006 1:33 am

Are you saying that I should name the file *.dll.ini ?

No. Just saying that a file extension does not make a file a particular type of file. A text file is a text file no matter what name it has. You can name your INI file "name.ini" or you can name it "name.qwerty", as long as you use the full name in the ReadIniFile> and EditIniFile> commands the files will be properly accessed..

I was suggesting that *.DLL files are typically not readable by text editors and therefore most people will not bother to try to look to see the contents of a file with a DLL extension. Therefore if you need to make your INItialization files inconspicuous on a network, name them something other than "name.ini".

Hope this makes sense.
Dick

esuohlluf · Post by **esuohlluf** » Mon Apr 10, 2006 1:49 pm

Yes, it makes sense.
I wasn't aware of that.

Thank You