Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Saving/creating and Loading files

Saving/creating and Loading files

Scheduled Pinned Locked Moved C / C++ / MFC
c++questionjsontutorial
9 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Kayembi
    wrote on last edited by
    #1

    Hi, This is probably going to seem a very dumb and easy question to many (I hope!), but I am a novice with C++ so please bear with me... I have an application that saves certain settings to file, and loads them on opening. All of these settings are just simple strings and integers, so at the moment I just save them to a (renamed) INI file using WritePrivateProfileString() and load them using GetPrivateProfileString() and GetPrivateProfileInt(). However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Ideally, I would like to create saved files that can't be opened in a text editor. Could anybody tell me how to do this, please? (I am using the Windows API but *not* using MFC.) If somebody could show me a function (or tell me where to look) that creates a save file, and then can save strings and integers to it, and also a function on how I would then read the information back (load it), I would be very grateful. (One advantage with using the PrivateProfile functions is that I can read whatever value I want arbitrarily without having to load the info of the whole fle - can this functionality be maintained in a custom file?) Many thanks, KB

    L L D 3 Replies Last reply
    0
    • K Kayembi

      Hi, This is probably going to seem a very dumb and easy question to many (I hope!), but I am a novice with C++ so please bear with me... I have an application that saves certain settings to file, and loads them on opening. All of these settings are just simple strings and integers, so at the moment I just save them to a (renamed) INI file using WritePrivateProfileString() and load them using GetPrivateProfileString() and GetPrivateProfileInt(). However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Ideally, I would like to create saved files that can't be opened in a text editor. Could anybody tell me how to do this, please? (I am using the Windows API but *not* using MFC.) If somebody could show me a function (or tell me where to look) that creates a save file, and then can save strings and integers to it, and also a function on how I would then read the information back (load it), I would be very grateful. (One advantage with using the PrivateProfile functions is that I can read whatever value I want arbitrarily without having to load the info of the whole fle - can this functionality be maintained in a custom file?) Many thanks, KB

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      CreateFile in MSDN has all your answers for creating and opening files. WriteFile and ReadFile can do just what you want with them. When you master that, get onto File Mapping in memory for fast access to file data :)

      1 Reply Last reply
      0
      • K Kayembi

        Hi, This is probably going to seem a very dumb and easy question to many (I hope!), but I am a novice with C++ so please bear with me... I have an application that saves certain settings to file, and loads them on opening. All of these settings are just simple strings and integers, so at the moment I just save them to a (renamed) INI file using WritePrivateProfileString() and load them using GetPrivateProfileString() and GetPrivateProfileInt(). However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Ideally, I would like to create saved files that can't be opened in a text editor. Could anybody tell me how to do this, please? (I am using the Windows API but *not* using MFC.) If somebody could show me a function (or tell me where to look) that creates a save file, and then can save strings and integers to it, and also a function on how I would then read the information back (load it), I would be very grateful. (One advantage with using the PrivateProfile functions is that I can read whatever value I want arbitrarily without having to load the info of the whole fle - can this functionality be maintained in a custom file?) Many thanks, KB

        L Offline
        L Offline
        lawrence2000
        wrote on last edited by
        #3

        I think you can use register after i watched your requirement . i'm a software engineer

        1 Reply Last reply
        0
        • K Kayembi

          Hi, This is probably going to seem a very dumb and easy question to many (I hope!), but I am a novice with C++ so please bear with me... I have an application that saves certain settings to file, and loads them on opening. All of these settings are just simple strings and integers, so at the moment I just save them to a (renamed) INI file using WritePrivateProfileString() and load them using GetPrivateProfileString() and GetPrivateProfileInt(). However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Ideally, I would like to create saved files that can't be opened in a text editor. Could anybody tell me how to do this, please? (I am using the Windows API but *not* using MFC.) If somebody could show me a function (or tell me where to look) that creates a save file, and then can save strings and integers to it, and also a function on how I would then read the information back (load it), I would be very grateful. (One advantage with using the PrivateProfile functions is that I can read whatever value I want arbitrarily without having to load the info of the whole fle - can this functionality be maintained in a custom file?) Many thanks, KB

          D Offline
          D Offline
          David Crow
          wrote on last edited by
          #4

          Kayembi wrote: However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Is this a bad thing? If the settings are related to your application, what's the harm? Ideally, Win32 programs use the registry instead of text-based INI files. It's no more secure, at least not to any experienced person, but it does give your application more flexibility.

          K 1 Reply Last reply
          0
          • D David Crow

            Kayembi wrote: However, using these instructions means that anyone using my program can open the INI file in a text editor and look at the stored information. Is this a bad thing? If the settings are related to your application, what's the harm? Ideally, Win32 programs use the registry instead of text-based INI files. It's no more secure, at least not to any experienced person, but it does give your application more flexibility.

            K Offline
            K Offline
            Kayembi
            wrote on last edited by
            #5

            Thanks for the replies. I can live with INI files - it's not really a bad thing - but I just think it would be a little more "professional" if people can't look in the file. Also, I may need to store a password in there, in which case (although I could encrypt it in an INI file), a non-readable file would be better. Thanks again for the replies, I'm looking into all the suggestions on the MSDN site and trying to work it all out... It's still a bit complex for me as I'm still learning, but I'm trying... Cheers, KB

            D 1 Reply Last reply
            0
            • K Kayembi

              Thanks for the replies. I can live with INI files - it's not really a bad thing - but I just think it would be a little more "professional" if people can't look in the file. Also, I may need to store a password in there, in which case (although I could encrypt it in an INI file), a non-readable file would be better. Thanks again for the replies, I'm looking into all the suggestions on the MSDN site and trying to work it all out... It's still a bit complex for me as I'm still learning, but I'm trying... Cheers, KB

              D Offline
              D Offline
              David Crow
              wrote on last edited by
              #6

              Kayembi wrote: but I just think it would be a little more "professional" if people can't look in the file. Sometimes editing a file outside the app is the only way to get it to work. Kayembi wrote: Also, I may need to store a password in there... A very bad design.

              K 1 Reply Last reply
              0
              • D David Crow

                Kayembi wrote: but I just think it would be a little more "professional" if people can't look in the file. Sometimes editing a file outside the app is the only way to get it to work. Kayembi wrote: Also, I may need to store a password in there... A very bad design.

                K Offline
                K Offline
                Kayembi
                wrote on last edited by
                #7

                "A Very bad design" - you're right; I think I have eliminated the need for a password to be stored in the file, fortunately. Maybe you're right about leaving the files as INI files... The main reason I want to do it is that there is information in there that, if changed, will definitely cause the program to crash, or at least behave oddly. This is probably bad design again... Essentially I am writing a launcher app and a wizard. Through the wizard, users can choose different styles and settings for the launcher app. It then copies the launcher app, with the files it is launching, and the settings file (which is the file I am trying to save/load, currently an INI) to a new directory. Thus all of the settings they chose through the wizard (JPG to display while launching, titlebar name etc) are all saved in the INI file, and the launcher reads that in order to find the files it need to launch and to find the picture files it needs to display, etc. In an ideal world there would be no need for an INI or saved file at all - all the information would be stored inside a newly generated launcher executable, along with the JPG files that have been selected for use by the launcher. This would be tidier and more professional, but as I have no idea where to begin in trying something like that, I have to instead go the route of external files and an INI (or save file of another format). Many thanks for all your help, I really appreciate it, KB

                D 1 Reply Last reply
                0
                • K Kayembi

                  "A Very bad design" - you're right; I think I have eliminated the need for a password to be stored in the file, fortunately. Maybe you're right about leaving the files as INI files... The main reason I want to do it is that there is information in there that, if changed, will definitely cause the program to crash, or at least behave oddly. This is probably bad design again... Essentially I am writing a launcher app and a wizard. Through the wizard, users can choose different styles and settings for the launcher app. It then copies the launcher app, with the files it is launching, and the settings file (which is the file I am trying to save/load, currently an INI) to a new directory. Thus all of the settings they chose through the wizard (JPG to display while launching, titlebar name etc) are all saved in the INI file, and the launcher reads that in order to find the files it need to launch and to find the picture files it needs to display, etc. In an ideal world there would be no need for an INI or saved file at all - all the information would be stored inside a newly generated launcher executable, along with the JPG files that have been selected for use by the launcher. This would be tidier and more professional, but as I have no idea where to begin in trying something like that, I have to instead go the route of external files and an INI (or save file of another format). Many thanks for all your help, I really appreciate it, KB

                  D Offline
                  D Offline
                  David Crow
                  wrote on last edited by
                  #8

                  Kayembi wrote: The main reason I want to do it is that there is information in there that, if changed, will definitely cause the program to crash, or at least behave oddly. This is probably bad design again... A well-behaved app would indeed not crash, but should instead detect when "bad data" is present and respond accordingly. For example, if you were storing the window coordinates of the app when it was last shut down (t=0, r=1024, b=768, l=0) so that it could be positioned in the same spot next time, and someone changed those coordinates to something non-sense (t=768, r=1024, b=0, l=0), the app would know to correct the problem, or use some default values at the very least.

                  K 1 Reply Last reply
                  0
                  • D David Crow

                    Kayembi wrote: The main reason I want to do it is that there is information in there that, if changed, will definitely cause the program to crash, or at least behave oddly. This is probably bad design again... A well-behaved app would indeed not crash, but should instead detect when "bad data" is present and respond accordingly. For example, if you were storing the window coordinates of the app when it was last shut down (t=0, r=1024, b=768, l=0) so that it could be positioned in the same spot next time, and someone changed those coordinates to something non-sense (t=768, r=1024, b=0, l=0), the app would know to correct the problem, or use some default values at the very least.

                    K Offline
                    K Offline
                    Kayembi
                    wrote on last edited by
                    #9

                    Thanks. I guess I need to add lots of error-handling code to sort this out. I ought to get into good habits now, so thanks for the advice. Cheers, KB

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • World
                    • Users
                    • Groups