Dan Bookwalter Posted October 19, 2006 Report Share Posted October 19, 2006 on the one hand, this a good idea, on the other hand, it is not, because, you add some extra difficulties to your development:during development, it's easier to open an *.ini file with the notepad and edit some entries, than open regedit and edit data stored in the registry. if your software is in production, it is easier to request someone, "plz send me the *ini-file, I need to see your settings" than to request an export from the registry. maybe a combination of *.ini file and registry would be a good solution: when closing the programm, make a MD5 hash and store that hash in the registry. Then you can detect any changes and display a "corrupt file" message !? cheers, CB I thought about using the registry but i really dont want to get into that whole mess... i am going to try the checksum for now and TRY to force the burden back onto them.... maybe , just maybe , they will learn if they get burned a few times... luckily these guys dont fit into this category "Nothing is fool-proof for a clever fool." , but , i wish they would jsut stick to letting the program do what it is desinged to do , everything that needs to be done can be done from within the program i wrote.... oh well i guess it could be worse............. Quote Link to comment
crelf Posted October 19, 2006 Author Report Share Posted October 19, 2006 i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... heh heh heh Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up! Quote Link to comment
Ton Plomp Posted October 19, 2006 Report Share Posted October 19, 2006 heh heh heh Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up! I think we all sometimes mess around with INI files we shouldn't Ton Quote Link to comment
Dan Bookwalter Posted October 19, 2006 Report Share Posted October 19, 2006 heh heh heh Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up! Chris yeah i know , it just seems to be getting worse , i try to make my programs as flexible as possible so i dont have to keep editing etc... but it also tends to come back and bite me i the A** at times ah well jus a couple more hours then it's :beer: time.... i think it may be a Guinness night after the past couple of days. Dan Quote Link to comment
Jacemdom Posted October 19, 2006 Report Share Posted October 19, 2006 ARRRRRRGHHHHHHHHHHHHHH.....i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then Quote Link to comment
Dan Bookwalter Posted October 19, 2006 Report Share Posted October 19, 2006 I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then i dont want top resort to that , but , i may have no choice... Quote Link to comment
LAVA 1.0 Content Posted October 19, 2006 Report Share Posted October 19, 2006 i dont want top resort to that , but , i may have no choice... Maybe a VI that could do THIS would help ... Quote Link to comment
Jacemdom Posted October 19, 2006 Report Share Posted October 19, 2006 Maybe a VI that could do THIS would help ... Quote Link to comment
crelf Posted October 19, 2006 Author Report Share Posted October 19, 2006 Maybe a VI that could do THIS would help ... We've got to add that to our library!!! Quote Link to comment
LAVA 1.0 Content Posted October 20, 2006 Report Share Posted October 20, 2006 We've got to add that to our library!!! Done... Mmmm, good coffee.... Quote Link to comment
Mellroth Posted October 20, 2006 Report Share Posted October 20, 2006 ARRRRRRGHHHHHHHHHHHHHH.....i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... rather than go through all the hassles of changing everything over to hidden and encrypted files i have decided to play games with the techs and put the burden back on them... I think you can solve this issue by creating a LV exe that is run as a NT-service. The only thing this exe would do is to open the file/files and keep them opened. This will prevent any user from editing or deleting your files, but they can still be read. /J Quote Link to comment
Rolf Kalbermatter Posted January 11, 2007 Report Share Posted January 11, 2007 It seems to me that some sort of "encryption" will be necessary. I haven't used the technique, but there was a section (6.3) in "A Software Engineering Approach to LabVIEW" that discussed this EXACT problem, and presented a solution. You can download the examples from the book HERE. You would be interested in the CONFIG INI code. The idea is to replace the Config Data Read & Write vis in the Open Config Data and Close Config Data vis with the encrypted versions (downloaded from above). Maybe you could leave the NI libs alone and create a private version of the Open Config Data and Close Config Data vis. You could use case statements that key off of the Application:Kind property to select between using the unencrypted NI Open and Close INI vis during development and the encrypted when called from the runtime engine... I think a somewhat smarter way for ini files (and XML files are just as simple) would be to add an extra key such as SecurityHash=AB123FE45... Calculate that hash using all the key names and values of that section in a deterministic way combined with a hardcoded private key and a hash function such as MD5 or maybe better SHA-1. On load read that key and verify it. If failed use default data instead. After having had to enter a complete configuration two times most users will probably stop altering files (or be so pissed off that they won't use your application anymore ;-) Rolf Kalbermatter Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.