|
I would rather the user not see it all.  I agree that being portable is a great reason to use XML.
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
You are correct regarding the 32 bit/64 bit issue. The keys would be stored in separate points in the registry, however this should not be a problem generaly. The only issue is if you create registry keys as part of your installer (which is always 32 bit) then they will not be available to the appliction running in 64 bit. However if your app just generated the keys if missing then there is no problem.
As the other poster said, use of the registry makes you application non-portable, but that may not be an issue.
The main question should be, do you need secure storage of this information? If the answer is yes, then encrypt it and store it in the registry. If the answer is no then xml is the easier, quicker and more simply manageable route to take.
|
|
|
|
|
The Man from U.N.C.L.E. wrote: (which is always 32 bit)
Not true as of Windows Installer 2.0 when 64-bit support for IA64 platforms was added. That support has since grown to cover everything 64-bit available today.
|
|
|
|
|
Personally I hate Windows registry. I would stick with XML. Issues could arise from different machines but if you are accessing the registry locally then it shouldn't be a problem. What I am saying is if you develop a x86 application it will read from the x86 (wow6432node) on a x64 system.
Also I noticed you are trying to keep it away from the user. Just because it is in the registry doesn't mean it is secure. I would stick with XML and just encrypt your values and decrypt them in your application. This way a user cannot read it.
You could also run into permission problems using the registry. I've seen problems where people were running McAfee and it did some weird stuff with not letting values in the registry being edited/removed.
|
|
|
|
|
I use XML for simple things and a database for more complex things.
The registry is evil.
|
|
|
|
|
All of these answers have been great. I think I'll stick to XML.
PIEBALDconsult wrote: The registry is evil.
I'll stay away from the curse. 
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
It was repeated on the forum several times. Registry is bad. You don't know if your application's user will be able to access registry. Only administrators can do it (I don't remember how it was on Windows XP, but I'm sure that's true for Vista and 7). Another thing is that when your user wants to check, what you store, he can also check registry. It's not hidden from users. I would recommend (as people answered here) encrypting your XML configuration and store it somewhere in user profile directory. This way checking what you store will be difficult (but not impossible).
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
Btw, you probably know this, but you can't really keep anything from the user. Normal users aren't going to mess around with the registry or even XML files. Users like me will still mess around with encrypted data, and you can't do anything about it, the way to decrypt it will be in the application.
|
|
|
|
|
harold aptroot wrote: Normal users aren't going to mess around with the registry or even XML files.
You right. I seem to proccess the end user's mind set through my own curiosity driven brain. 
I store my XML file within the CommonAppDataPath folder which is buried deep inside the drive's root directory. This should be hidden enough for a normal user.
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
Most people don't even know that such a place exists
|
|
|
|
|
I've recently tried implementing single sign-on using a desktop application and gmail. I failed after numerous attempts. So I've got another question to ask before I go on a wild search on the Internet again. Do you think it would be possible to link a Gmail account with MS Outlook, and then integrate Outlook into a desktop C# application and access the Gmail account like that? Or maybe even using some other provider such as Hotmail? I need to have some sort of single sign on up and running using a desktop application soon and I'm quickly starting to run out of ideas 
|
|
|
|
|
Greetings,
Somehow the lenght of my file stream is 0.
Anyone could point me out why, please?
string path;
StringBuilder sb = new StringBuilder();
char c;
char[] temp = new char[10];
Boolean munching = true;
if (txtFilePath.Text != "" && txtFilePath.Text != null)
{
path = txtFilePath.Text;
if (File.Exists(path))
{
FileStream fs = new FileStream(@"C:\test.pdf", FileMode.Open);
BinaryReader br = new BinaryReader(fs);
while (munching == true)
{
br.Read(temp, 0, 10);
c = temp[0];
}
}
else
{
}
}
else
{
}
|
|
|
|
|
Bazewouelle wrote: Somehow the lenght of my file stream is 0.
What is the content of path and the length of C:\test.pdf?
It's time for a new signature.
|
|
|
|
|
Somehow, the pdf had reset to 0 bytes... (?)
thanks again,
|
|
|
|
|
I see strange things:
1.
you have a something (probably a TextBox) that holds a path, yet you do not use its content. Instead you open a fixed file.
2.
If txtFilePath really is a TextBox, no need to test for Text==null as TextBox.Text never holds null, it always holds a real string ("" if no data is present).
3.
your while loop is bizarre.
4.
what makes you think the FileStream has length zero? there is nothing in the code to indicate that.
BTW: as you have been trying to extract text from a PDF file, which isn't necessarily all text, the whole approach is wrong. You should read the entire file as binary bytes, why not use File.ReadAllBytes()?
|
|
|
|
|
thanks Luc, this helps too
|
|
|
|
|
If fs.length is 0, then there's nothing in your file.
And I want to point out something Luc said. Your while loop is an infinite loop. You never change munching, so munching will always be true.
Also, while we're talking about it...you don't need to test a boolean against a value within a while loop. You're simply adding an extra test that is unnecessary.
while (munching)
is the same as
while (munching == true)
and uses one less evaluation. If you want to test against false, you would write
while (!munching)
|
|
|
|
|
Thanks for the advice, its appreciated.
|
|
|
|
|
Hallo
I need to display in a TreeView an array with three fields: DisplayName, Value and Level (0-1) which determines if it is a child or a node.
Is there any way in .Net 2.0+ to bind a treeview to an array in the fashion of the ListBox, using DataSource, DisplayMember and ValueMember? (maybe the Level could be managed in a separate way)
I found a code snippet using these properties but it doesn't work, it seems dated back to earlier .Net, 1.1 or 1.0
Or should I go straight using an iteration that loops through the array?
Thanks in advance
|
|
|
|
|
The .Net treeview does not natively support binding like this. While you should indeed iterate though the array creating the appropriate nodes it would probably be best to subclass the treeview and add your own binding code so you can reuse it. Unfortunately the binding code would have to iterate through the datasource, and the structure would have to be fixed.
|
|
|
|
|
|
Greetings,
Here is an interesting question I hope.
In a nutshell, I am trying to convert to UTF8 an 8 bit encoded binary file and display into a RichTextBox.
I am learning to program against the Adobe PDF file format. The PDF Reference 1.7 tells at page 38 (2.2.1) that "PDF files are represented as sequences of 8-bit binary bytes".
In the hope of learning by looking at the source code of PDF documents, I created a very simple hello world text file in Notepad and printed it as PDF with all distiller options turned off. When you rename the test.pdf created as text.txt and view the result in Notepad you see an Ascii rendition of the 8 bit base code. You see enough readable material to understand what's going on.
Now when I load up that test.txt into a richtextbox, a part of the file (the bottom end, is missing). If I attempt to read the PDF directly using a binary reader I get the same results. So viewing the source in Notepad shows more than it does in a RichTextBox.
PDF experts recommends to convert to unicode first before displaying the source of a PDF.
So my question is how does one take a binary file, convert it to UTF8 and display it properly in a RichTextBox (w2k3r2sp2 with vs2010)?
And also, why is the richtextbox not displaying the bottom part of the file? Is there illegal characters in UTF8 or something to that effect?
I know its a lengthy question, and I appreciate your time. I spent all day yesterday in a rather futile effort at this...
Thank you!!
Antoine
|
|
|
|
|
You cannot do this with a PDF file (or many other binary types), as there is no direct correlation between binary data and text data. The structure of a PDF file includes dictionary elements, pointers, fonts, images etc that cannot be rendered directly into text, except with a program that can interpret the structure of the PDF file itself. Take a look at the PDF reference on the Adobe web site[^] for more information.
It's time for a new signature.
|
|
|
|
|
Hi Richard,
Thank you for answering.
I understand that that most text, fonts and graphics objects will be streamed into binary and FlateEncoded. I've read a few chapters so far. However here my purpose is not to retain the binary stream exactness but simply to see the variables names and their order. By converting to UTF8 the whole thing I will for sure break the pdf however I'll get to see somewhat the file structure and the elements name etc.
Please let me know if you can assist.
Thanks,
|
|
|
|
|
Bazewouelle wrote: I will for sure break the pdf however I'll get to see somewhat the file structure and the elements name etc.
Well, you may 'see' some of these things but that will not help with interpreting the content of the PDF. You will need to study the PDF reference document to understand how to extract the actual content from the file. One of the first things to understand is the dictionary structures as mentioned in the reference thus:
To support such random access to individual objects, every PDF file contain a cross-reference table that can be used to locate and directly access pages and other important objects within the file. The cross-reference table is stored at the end of the file, allowing applications that generate PDF files in a single pass to store it easily and applications that read PDF files to locate it easily. Using the cross-reference table makes the time needed to locate a page or other object nearly independent of the length of the document. This allows PDF documents containing hundreds or thousands of pages to be accessed efficiently.
It's time for a new signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
