|
SledgeHammer01 wrote: Seems like a security / permission problem to me.
That's what I thought, but I'm running as an admin, with no restrictions that I know of. It's a WPF app.
Everything makes sense in someone's mind
|
|
|
|
|
Do you have a try / catch hiding exceptions at some level? That method throws an exception on errors. Looking at the .Net source, the only way you should get a null is if the Win32 native function is returning an error other then security. Unfortunately, .Net hides the real error code from you. You might want to call the native RegOpenKeyEx through interop so you can get the real error code.
|
|
|
|
|
Based on your previous message, this cannot be true, since you stated that the key returned from this method is null. You need to use your debugger to see what value is being passed in to your code in the first place.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
I said OpenSubKey is returning False.
_GetRegistryBaseKey return the correct base key. Then the call to OpenSubKey returns False.
Everything makes sense in someone's mind
|
|
|
|
|
Well my previous comment still stands; you need to use your debugger to check all values to determine why OpenSubKey() returns null. With the information you have provided it's impossible to guess what values exist within your application.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
Hi,
I have done some searching for this and have not found exactly what I need.
I have created a Windows Application in C#, Dot Net Framework 2, for my company. It currently has a Target Platform of "any cpu".
The company is slowly migrating to use 64 bit machines. Also we would like to upgrade the Windows Application to Dot Net Framework 4.
Management wants to be sure that changing to an x86 target platform (this is the target platform that needs to be used for both x32 and x64 bit machines to run the application) and changing to Dot Net Framework 4, will not break anything.
So: For testing, I want to create 2 applications with the same source code.
1) (Using Visual Studio 2005 to build and publish): Current Visual Studio settings: Dot Net Framework 2, and Target Platform: any cpu
2) (Using Visual Studio 2010 to build and publish): Dot Net Framework 4, and Target Platform: x86
In a label on the application, I want to display the Dot Net Version (I know how to do that). Then I also want to display the Target Platform, which will either be : "any cpu" or "x86".
After searching the internet for about 15 minutes, I discovered how to differentiate between, x32 and x64; or perhaps between x32 and x86... This is by simply using the IntPtr.Size property.
But.. How would I differentiate between "any cpu" and x86. Or what if I wanted to differentiate between x86 and x64?
Thanks in advance for any advice anyone can give me with this.
 Anne
|
|
|
|
|
The whole idea of the 'Any CPU' setting is that it runs on both x86 (32 bit) and x64 (64 bit). Unless you're running into a specific problem that can be resolved by selecting x86 or x64, you should probably leave that setting on Any CPU.
Now to answer your actual question:
If you build x86, you will then IntPtr.Size will be 4. If you build x64 IntPtr.Size will be 8. If you build Any CPU, IntPtr.Size will be 4 on 32 bit windows and 8 on 64 bit windows. So that won't help identify the Any CPU compiler setting.
So, you would need to create 3 project files (2 copies of the original), then add a Conditional Compilation Symbol in each of the project files. Then set the Label's text based on those symbols.
string platformTarget = "unknown";
#if x86
platformTarget = "x86";
#elif x64
platformTarget = "x64";
#elif AnyCPU
platformTarget = "AnyCPU";
#endif
lblPlatformTarget = platformTarget;
You can do something similar with comparing Framework 2 and 4. The upgrade from 2 to 4 should be completely painless.
|
|
|
|
|
any cpu:32 bit machine
x86: 32bit or 64 bit machine
x64: 64 bit machine
|
|
|
|
|
don't think so.
|
|
|
|
|
x86 could run in x64 platform and x32 platform. I used.
|
|
|
|
|
any cpu: 32 bit machine code runs in 64-bit mode on Win64, in 32-bit mode otherwise (i.e. Windows decides based on Win itself and CPU)
x86: 32bit or 64 bit machine code runs in 32-bit mode (or not at all when future x64 CPUs no longer support x86)
x64: code runs in 64-bit mode on x64 CPUs and Win64, or not at all.
For all of them, the process needs to be homogeneous; if parts (referenced DLLs) contain native code of the other persuasion, the app won't load.
|
|
|
|
|
I see.
Thank you very much.
|
|
|
|
|
Apart from the application, you should also test your development environment: developing 32bit applications with VisualStudio 2010 on a Windows 7 (64bit) computer may require some strange settings - it was hard to get it working correctly in our case. Therefore, test also that point.
|
|
|
|
|
Hello,
What is good practice to load an object from a data source?
1 - Static method that returns the object.
2 - Constructor with parameter.
Thank you.
|
|
|
|
|
Use a DataReader.
Yes, if it's merely filling an ActiveRecord-object, then I'd expect initialization using a constructor. No, if it's merely a query that returns a value or a reader, then I'd expect a static method that returns that.
Bastard Programmer from Hell 
|
|
|
|
|
The problem with best practices is they are different for different projects and usages. It's your job to understand what the practice is, how it should be used and whether it fits for the goals in your particular usage.
Failure is not an option; it's the default selection.
|
|
|
|
|
|
You know that's not an answer right? Yes, it's our jobs know and understand best practices, but before you can do that you need to learn them. One way to learn is to ask.
|
|
|
|
|
You know that's not a question right?
Failure is not an option; it's the default selection.
|
|
|
|
|
I agree with Eddy (and Mark). I generally use a constructor to do that. But first you need to be really sure that you need an object; I very rarely use custom objects, the existing DataTables and DataRows usually suffice for my needs.
|
|
|
|
|
I tend towards the static method mostly for consistency sake. If I need to return a list of those objects, which I often do, then I want a static method that queries the datasource once and returns a list of the objects.
I don't want that list retrieval method to make a bunch of calls to the objects constructor only to have the object query the datasource.
And of course I want to be able to get a single object in a similar manner as I get my list, thus static methods all the way.
I'm sure an argument can be made for the 'constructor with parameter' way as well. These things are almost never black and white.
|
|
|
|
|
I prefer not to have the object class query the datasource -- I think that couples the class too tightly to the datasource. By using constructors I can instantiate the class from different sources (IDataRecord, XML, etc.) as the situation requires.
In my opinion the class shouldn't know how, where, or whether the data is persisted. I realize that this may be an unpopular point of view. 
|
|
|
|
|
That makes a lot more sense than have a constructor querying the database.
I've never worked with a code base that did it that way, but I'm going to keep that method in mind for the next greenfield project I work on.
|
|
|
|
|
PIEBALDconsult wrote: I realize that this may be an unpopular point of view.
Unpopular with whom? IMO this is the correct way also.
Failure is not an option; it's the default selection.
|
|
|
|
|
Thank you for your response
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
