Saving File Formats
-
I feel like I should know this question, but it seems to me to be harder than I want it too. Preface: I am working on a windows GUI interface for a embedded system. My boss wants to save off the current state of the system in to a file. However he has laid some requirements on the file format 1) it should be hand editable, 2) other applications should be able to open it, and 3) we don't need to rely on the having an outside application. My boss understands enough about software to be annoying and he is insisting that the file save be ODBC, however I admit I am not familiar enough with it. I do realize that you need to register a datasource and I am not sure how to do this on a different machine. My predecessor wrote the GUI in VB and he saved the file in Access format which was not hand editable. I have cruised the site here and found some nice demonstrations. I had orginally thought that I would save the file in an Excel format. I noticed it used ODBC and my boss would be pleased. However I began to be concerned that it might fail on machines that don't have excel. We cannot require installation of Excel on a machine to run our GUI. I think automation solutions I found on Microsofts site will also have this problem. I am not sure how the orginal VB code got around this problem with the Access format file using type libraries. (Not real familiar with those either.) Does anyone have any advice on what to do and where to find documentation on doing it? I mean I can use ODBC if I can find a way to automate the registration of the data source.. but I need to brush up on this stuff again.. Thanks for any help, Brian If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
-
I feel like I should know this question, but it seems to me to be harder than I want it too. Preface: I am working on a windows GUI interface for a embedded system. My boss wants to save off the current state of the system in to a file. However he has laid some requirements on the file format 1) it should be hand editable, 2) other applications should be able to open it, and 3) we don't need to rely on the having an outside application. My boss understands enough about software to be annoying and he is insisting that the file save be ODBC, however I admit I am not familiar enough with it. I do realize that you need to register a datasource and I am not sure how to do this on a different machine. My predecessor wrote the GUI in VB and he saved the file in Access format which was not hand editable. I have cruised the site here and found some nice demonstrations. I had orginally thought that I would save the file in an Excel format. I noticed it used ODBC and my boss would be pleased. However I began to be concerned that it might fail on machines that don't have excel. We cannot require installation of Excel on a machine to run our GUI. I think automation solutions I found on Microsofts site will also have this problem. I am not sure how the orginal VB code got around this problem with the Access format file using type libraries. (Not real familiar with those either.) Does anyone have any advice on what to do and where to find documentation on doing it? I mean I can use ODBC if I can find a way to automate the registration of the data source.. but I need to brush up on this stuff again.. Thanks for any help, Brian If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
I seem to recall seeing a recent article that addressed creating a .XLS file even if there wasn't an ODBC driver for Excel installed. However, all I can find was the following: http://www.codeproject.com/database/excel\_odbc\_write.asp Try that other site, codeguru.com, too.
-
I seem to recall seeing a recent article that addressed creating a .XLS file even if there wasn't an ODBC driver for Excel installed. However, all I can find was the following: http://www.codeproject.com/database/excel\_odbc\_write.asp Try that other site, codeguru.com, too.
Thanks for the suggestion, but I checked out the "other site" and the articles on Excel. They all require excel ODBC drivers to read and write files. I need to learn how to automated create ODBC or DAO drivers. I just need a method of letting others use additional software to edit the file outside of the actual GUI program. I will keep looking... Brian If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
-
I feel like I should know this question, but it seems to me to be harder than I want it too. Preface: I am working on a windows GUI interface for a embedded system. My boss wants to save off the current state of the system in to a file. However he has laid some requirements on the file format 1) it should be hand editable, 2) other applications should be able to open it, and 3) we don't need to rely on the having an outside application. My boss understands enough about software to be annoying and he is insisting that the file save be ODBC, however I admit I am not familiar enough with it. I do realize that you need to register a datasource and I am not sure how to do this on a different machine. My predecessor wrote the GUI in VB and he saved the file in Access format which was not hand editable. I have cruised the site here and found some nice demonstrations. I had orginally thought that I would save the file in an Excel format. I noticed it used ODBC and my boss would be pleased. However I began to be concerned that it might fail on machines that don't have excel. We cannot require installation of Excel on a machine to run our GUI. I think automation solutions I found on Microsofts site will also have this problem. I am not sure how the orginal VB code got around this problem with the Access format file using type libraries. (Not real familiar with those either.) Does anyone have any advice on what to do and where to find documentation on doing it? I mean I can use ODBC if I can find a way to automate the registration of the data source.. but I need to brush up on this stuff again.. Thanks for any help, Brian If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
It depends on how complicated the state information is. Simple options would be: 1. Use ini files (WriteProfileXxxx and GetProfileXxxx) 2. Write csv files. They can be opened in Notepad, Excel, Access etc., etc. Get some code from CP to handle csv files or write your own, it's pretty easy. 3. Use XML. There are several examples on CP of loading and saving configuration to XML. It's not so easy to hand edit (and fairly easy to screw it up) but it can be done.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
-
It depends on how complicated the state information is. Simple options would be: 1. Use ini files (WriteProfileXxxx and GetProfileXxxx) 2. Write csv files. They can be opened in Notepad, Excel, Access etc., etc. Get some code from CP to handle csv files or write your own, it's pretty easy. 3. Use XML. There are several examples on CP of loading and saving configuration to XML. It's not so easy to hand edit (and fairly easy to screw it up) but it can be done.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
Phil J Pearson wrote: . Use XML. There are several examples on CP of loading and saving configuration to XML. It's not so easy to hand edit (and fairly easy to screw it up) but it can be done. you can use MC++ and
DataSetbut then you need to use MC++ :( Rickard Andersson@Suza Computing C# and C++ programmer from SWEDEN! UIN: 50302279 E-Mail: nikado@pc.nu Speciality: I love C#, ASP.NET and C++! -
I feel like I should know this question, but it seems to me to be harder than I want it too. Preface: I am working on a windows GUI interface for a embedded system. My boss wants to save off the current state of the system in to a file. However he has laid some requirements on the file format 1) it should be hand editable, 2) other applications should be able to open it, and 3) we don't need to rely on the having an outside application. My boss understands enough about software to be annoying and he is insisting that the file save be ODBC, however I admit I am not familiar enough with it. I do realize that you need to register a datasource and I am not sure how to do this on a different machine. My predecessor wrote the GUI in VB and he saved the file in Access format which was not hand editable. I have cruised the site here and found some nice demonstrations. I had orginally thought that I would save the file in an Excel format. I noticed it used ODBC and my boss would be pleased. However I began to be concerned that it might fail on machines that don't have excel. We cannot require installation of Excel on a machine to run our GUI. I think automation solutions I found on Microsofts site will also have this problem. I am not sure how the orginal VB code got around this problem with the Access format file using type libraries. (Not real familiar with those either.) Does anyone have any advice on what to do and where to find documentation on doing it? I mean I can use ODBC if I can find a way to automate the registration of the data source.. but I need to brush up on this stuff again.. Thanks for any help, Brian If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
Requirement 3 would seem to limit you to flat ASCII files that could be viewed/edited in Notepad or Wordpad. You can then create an ODBC data source that will let you manipulate the file via ODBC and satisfy that requirement. Strange though. The requirements seem to have arisen from different goals: hand editability and independence from outside application vs. standardization of the interface allowing substitution in the data source.
-
Requirement 3 would seem to limit you to flat ASCII files that could be viewed/edited in Notepad or Wordpad. You can then create an ODBC data source that will let you manipulate the file via ODBC and satisfy that requirement. Strange though. The requirements seem to have arisen from different goals: hand editability and independence from outside application vs. standardization of the interface allowing substitution in the data source.
;) Tell me about it. My boss laid down the requirments at just the right level to be dangerous without exactly knowing what he wants. Now I am just researching what I can actually give and then counter proposal time... If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
-
;) Tell me about it. My boss laid down the requirments at just the right level to be dangerous without exactly knowing what he wants. Now I am just researching what I can actually give and then counter proposal time... If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
Just write to a plain ASCII text file. It can be edited with notepad, wordpad, UltraEdit, ... you name it. Then tell your boss that you use something like Online Dirty Binary Conversion (=ODBC) logic (or invent a nice acronym yourself). :) Enjoy life, this is not a rehearsal !!!