We Keep Coding

Best way to store text in UWP application

I'm quite new to programming.
I'm making an UWP application, and on one of the pages I want to display a bunch of laws and regulations.
Where should I store the text/paragraphs?
I do not want to write them all in the XAML file, as this will take a lot of space and make
the XAML file hard to navigate and read.
I know it's possible to store text-strings in a resource file (.resw), but for me it seems like this is made for storing strings in different languages.
Should I store the strings in a database, SQL? I have not worked with databases before but
I'm eager to learn it if that's the way to go.
I have added a picture of what the law-paragraphs looks like (the text is in norwegian).
The paragraphs will be displayed in different frames on the page. It would be nice if I could easily add and edit text in the database.
Paragraphs

Best way to store text in UWP application
You have many ways to store the text, you could create txt file in your local folder and write the text in it, and here is document how to read and write data into file.
I checked your law-paragraphs, it's not very long string, so you could use LocalSettings to store this law-paragraphs with specific key quickly. Each setting can be up to 8K bytes in size and each composite setting can be up to 64K bytes in size. For more info please refer this document.
And we don't suggest your store this simple law-paragraphs string with SQL, it's too heavy, if you do want it, please refer Use a SQLite database in a UWP app

Where do exe save user input?

I am new to coding and trying to understand something. I have read that a .EXE can not change itself or change embedded files inside itself. So lets say you make a game and that game has setting that the user can adjust like difficulty or level or whatever. Maybe it is an RPG game and they need to save progress. Where does that information get saved? If you save it to a text file then the user could go into the text file and adjust their level and cheat. Also you would not save a password to a text file because then anyone could open the text file and see the password.
Another problem would be that, if they moved the game to a different computer and did not also move the save file they would not have access to their saved information.

For C# applications, there are several ways to save application data; various practices are dicsussed in this question; the most usual ways are custom data files (Xml, Json, binary formats), the Windows registry, or the cofiguration settings file of the application. The problem that a user could manually edit the saved data is always present and somewhat unrelated; this is a drawback of either possibility. One solution would be to encrypt the saved data or use checksums to detect manipulation.

Creating RTF and printing as PDF

I'm trying to do the following(in this order):
Create a Rich Text Format file
Add company image to the top of page and write the data to the RTF
Print the RTF file as PDF through CutePDF or other printer that are
able to convert my RTF to a PDF and thereby save locally on the users PC - The pdf should be saved at a location without prompting the user
After this is done, the RTF file should be deleted and return a message, that confirms the action is successfully done.
Other stuff:
The website where these actions take place, are not meant to host the outcome(the PDFs) but these are supposed to be saved on the users PC. (is this possible without prompting the user to save it? i imagine the website would write directly to the users PC instead of doing the work on the website and save it and then transfer the file to the PC)
OBS: i do not wish to use any 3th party program/DLL other then the converter like cutePDF :)
My question is quite simple i hope :)
Will this work?

No. You can send the PDF back to the user but the user will either be prompted to download the file or it will open automatically (depending on the user's configuration and the response headers you're sending). Without using some sort of plugin you can't save any files directly to the user's computer.
If it was possible to write a file directly to the user's the world as we know it would have ceased to exist. Cities would lie in ruin as idle youtube commentators roamed the streets in violent gangs yelling "FIRST" and engaging in brutal and pointless gang wars. A generation of youth superbly trained by video games would manage to destroy civilization in a matter of days. Fortunately civilization would eventually be rebuilt by Minecraft players but it would take time.
If that functionality is really vital I would suggest looking at a plugin.

Does XDocument.Save(string filename) resave the whole file or just changes?

Basically if I do Xdoc.Load(filename), do some changes then do Xdoc.Save(filename) does it only save things that changed such as inserted or removed elements, etc, or does it resave everything?
Depending on the answer I'm thinking of determining whether my app is going to save per-change or save on explicit save and on exit. Also considering whether to write to multiple xml files or just keep everything in one big file. I have no idea how big the one big file would be but I suspect it could potentially be 10's of MBs, so if it's resaving the entire file then I definitely can't be saving every change while keeping one big file.
If it does save the entire file, does anyone have opinions of having a separate xml file for each entity (potentially hundreds) and whether or not it's a good idea?

It saves the whole file. That is the nature of text based formats. A text file cant overwrite itself without rewriting the unchanged parts.

Yes, saving a document saves the whole document.
What's the use case for the "per change" save? Is it just in case the application crashes? If so, I suggest you save these incremental changes in a temporary directory as small files, but when the user explicitly says to save the file, save it in one big file. (That's easier to copy around etc.) Delete the temporary directory on exit.
I do wonder whether you really need the temporary directory at all though. It sounds like quite a lot of work for little benefit.

C#: capture data, display to user, save to disk, upload to database: BEST approach

I have a program that captures live data from a piece of hardware on a set interval. The data is returned as XML. There are several things I would like to do with this data (in order):
-display it to user
-save it to disk
-eventually, upload it to database
My current approach is to take the XML, parse it into a hashtable so I can display the correct values to the user.
Next, I want to save the XML to a file on disk. For each data capture session I am planning on creating a unique XML file and I will dump all the data into it.
Finally, I would like to reparse the XML and upload it to a MySQL database. The data cannot be immediately uploaded to the database.
This seems really inefficient method of solving this problem and I would love some advice.
Is it a waste of hd space to save the data as XML?
Is it THAT inefficient to have to reparse the XML in order to write it to a database?
Thank you!
To clarify: a typical XML response will be ~1kb and are captured at a rate of about 1 response every 15-60 seconds.
I think I do want to store the XML as XML on the disk because the data is very valuable and a pain to reproduce (if it is even possible). Thank you!

When you receive a new XML document from the source, directly save to disk and parse it to display to the user.
With a background process, or user initiated, read the xml files from disk and send them to the server based on created date (so you can retrieve only the latest ones) for insert into MySql.

That mostly depends on the amount and rate of data you're moving. If you have to upload to the database seldom and it only takes a few seconds, the flexibility of XML is surely good to have. If you're never using the locally stored data except to upload it to the database and parsing takes a few minutes you might want to rethink the strategy.

perhaps there should be a seperate thread for the data fetching and the processing.