Click here to Skip to main content
15,113,153 members

Comments by AnotherKen (Top 10 by date)

AnotherKen 24-Jun-19 21:17pm View
I tend to use a boolean variable to store the object's existence state in. So I would do something like:

if !form1Exists
Form1 form1 = new Form1();
form1Exists = TRUE;

I would declare the boolean variable form1Exists and probably form2Exists also as global variables, that way I don't have to worry about loosing the value if the routine that sets it goes out of scope.

I would also set that value to false if I knew that form was closed.
AnotherKen 14-Aug-18 12:22pm View
Ok, well, the error message means you tried to use an uninstantiated object. Either a property or method. This throws an error because if the object is not instantiated, it does not exist on the heap which is where it is looked for when you try to access it, that causes an exception to be thrown. Any object you use, even one in a library you did not write, has to be insantiated with the NEW keyword so that you can use it.
AnotherKen 1-Apr-15 0:45am View
Thanks Dave, that is more or less what I had assumed, I was hoping there would be an easier way since HP is a little tight lipped about this at the moment.
AnotherKen 1-Apr-15 0:44am View
Good point there, I was able to find it's ip-address and change the sleep time to 15 minutes. I guess I will still have to wait and see if HP will provide a SDK that will let me see if I can get the printer to wake up when it is asleep.
AnotherKen 17-May-13 15:41pm View
I have gotten to the point where I agree that I can use RSA Asymmetric encryption for the application I am working on. My initial tests are now working. I had originally gone with AES because it was easier to pickup and use than RSA, but with time I was able to find the information I needed to get RSA encryption working. Thank you for taking the time to respond to my question.
AnotherKen 17-Apr-13 15:45pm View
Thank you jsolutions_uk, that is helpful. I will investigate the use of RSA encryption, since that sounds more promising for this application.
AnotherKen 17-Apr-13 3:13am View
That is certainly one option, another is one I was reading about where you can setup an encryptor that only works for the currently logged in user. But in those cases I am just saving the key into a file. I have heard of storing keys in the registry but that seems no more secure and possibly prone to pruning by registry cleaning programs (assuming you are clever enough not to directly associate the key pair with the application that uses it.) This is why I was asking about the security of the Microsoft provided key containers. That one is still an unknown to me.
AnotherKen 17-Apr-13 3:05am View
one thing that tripped me up on this originally was that I learned belatedly that you have to set the resource file's build attribute to "embedded resource" to get a valid assembly reference to it. This is easy enough to do with the Visual Studio IDE, it should be possible to do this directly from the code too.

The extraction code that works for me is based on this:

Assembly assembly = Assembly.GetCallingAssembly();
string resourceName = assembly.GetName().Name + "." + rName.Replace(" ", "_").Replace("\\", ".").Replace("/", ".");
Stream keyStream = assembly.GetManifestResourceStream(resourceName);

in that example, rName was defined earlier and in this case is just the name of the embedded text file.
AnotherKen 17-Apr-13 1:44am View
Do you have the option of re-writing the services.dll to make it expose methods that you need? I am sort of thinking along the lines of public "accesor" methods which could be designed to give you the functionality you need without exposing private data or methods.
AnotherKen 17-Apr-13 1:14am View
ok, in this context what I intend to do is offer the user a way to "securely" store a key for local use only. This key would not be intended for passing along to other systems. The data I am encrypting basically just sits on the HD the application is installed to. I could store a key file of my own devising in the same location but this seems less secure than storing it in some completely different way to try to make it harder for a hacker to figure out what keys are being used.