|
If I understand what you are asking for I think you could solve it without making the sexe a custom object. Make sexe an "int" and then add this:
public class humanSex
{
public const int Male = 1;
public const int Female = 2;
}
You then would reference it to something like:
if (person.sexe == humanSex.Male)
|
|
|
|
|
Or better yet, because an enum's underlying type is an int, he could do this:
public Enum Sex
{
Male = 1,
Female = 2
}
and then check with the same thing as you have above.
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
|
Okay okay...you win.
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
I'm designing an application in C# and I want UI a bit more exciting than the standard windows effort.(Think winamp or mediaplayer skins)
What is the best way to go about this?
Using a standard Forms.Form and and try and intercept Non client Draw commands?
Or start from the ground up inhieiting from something above form?
Help Appreciated
Conor
|
|
|
|
|
You can buy a GUI package like SharpLibrary, you can do owner-drawing yourself (alot of work), or you can wait a few months for Fluid to come out (see sig).
There are also some good skinnable controls on CP, but precious few now that Carlos Perez took his controls off.
|
|
|
|
|
jdunlap wrote:
or you can wait a few months for Fluid to come out
Have you guys actually started any work on this yet? Or is it just a bunch of flashy HTML pages and diagrams?
I'm just kidding, I'd just like to know where you guys are on the timeline.
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
David Stone wrote:
Have you guys actually started any work on this yet? Or is it just a bunch of flashy HTML pages and diagrams?
About 10,000* lines of code and growing. We'll release some basic controls in 1 1/2 - 2 months (probably 2).
[EDIT] * 8000 lines for C#, 2000 for C++. We are behind on C++ because of troubles w/ our dictionary and collection classes. [/EDIT]
|
|
|
|
|
jdunlap wrote:
About 10,000* lines of code and growing
Wow.
jdunlap wrote:
We'll release some basic controls in 1 1/2 - 2 months (probably 2).
Sounds like fun. I'm looking forward to it. I looked over your diagrams a few weeks ago and they look great...very .NET-ish.
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
Let me toss in a vote for 'Just Say No'. The whole craze for skinnable applications is a bad bad thing from a user interface design/human factors perspective. It's a throwback to the days of DOS when ever application had a unique UI and everyone had to learn how to work the 'exciting' widgets and controls that application came up with.
I know it's all the rage, but please, think of the users and resist.
Just my ever humble opinion, of course....
--
-Blake (com/bcdev/blake)
|
|
|
|
|
It depends on what kind of skins you are talking about. The kind of skins that you find in Media Player and Real Jukebox sacrifice usability, whereas skins like Watercolor or other XP skins do not. A skin needs to be enough like the normal controls in that OS. That way, users can still get visual clues as to what each thing's function and state is.
|
|
|
|
|
|
Any one got any examples of drawing on NC areas of the form?
|
|
|
|
|
Hiya I am trying to use a C# dll from my MFC program. But am having a big problem.
To use the C# dll, I have changed the compiler settings in my MFC program to - Use Managed Extensions and have included #using <mscorlib.dll>.
But as soon as I change to use managed extensions, my program will not run.
I am using .Net Framework Ver 1.1 on the target machine.
Am I doing something wrong or is there another way??
Thanks.
|
|
|
|
|
Hi,
We are building a big WinForms application that references to about 30-35 assemblies (that's a lot of code, you know! :wtf
I'd like to know if there is a way to preload assemblies, when the application starts up (for example) in order to avoid delays once the application is loaded. The problem right now is that when the user opens a form for the first time, it takes a few seconds because some 3rd party controls and some other assemblies need to compile (JIT). The same window opens very quickly in subsequent calls. I'd like to have the form open quickly even on the first call.
Is there an easy way to do this?
Thanks!
Carl
|
|
|
|
|
Hmm... I'm not sure right off if there's a way to pre-load them, but you might instead try ngen'ing them when they're installed, so that thy don't have to be JIT compiled when they're loaded.
|
|
|
|
|
The problem with ngen is that it hurts the runtime performances. Preloading the assemblies would be the best solution for me since I can tolerate a delay while loading the application (a splash screen could inform the user of what's going on), but slow responsiveness is not an option for us.
Thanks!
Carl
|
|
|
|
|
Carl Mercier wrote:
The problem with ngen is that it hurts the runtime performances.
So slightly that you won't notice it, if any at all. What ngen does is just pre-compiles the executable into a native image, the same way it would be done at runtime with JIT.
|
|
|
|
|
Carl is correct - ngen'ing things does introduce an extra level of indirection to all assembly level statics. This can be a significant performance hit in some situations. There is no way to definatively state that ngen will be a win or a loss for a given application, the only thing you can do is profile it both ways yourself.
Through version 1.1 ngen's target is really for use with the framework assemblies themselves. Don't assume it's actually a win for your application. There's a good piece of this in one of the gotdotnet blogs recently but I don't have a link handy.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Blake Coverett wrote:
There is no way to definatively state that ngen will be a win or a loss for a given application, the only thing you can do is profile it both ways yourself.
It looks like this just may be a case where it is a win, though.
|
|
|
|
|
No, that was my point, there is _no_ way to tell a priori if it will be a win, you have to test and time for the specific application. And then of course, you have to figure out how you will handle the fact that anytime a CLR service pack is installed after your application you lose your ngen'd images. It is a hard problem and not well supported with the current tools.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Blake,
Do you know any way of preloading the assemblies by any chance?
Thanks
|
|
|
|
|
Heh, I guess we did get distracted from the original question there - sorry.
I guess the correct answer is, that depends. What do you mean by 'loading the assembly'. You can certainly force assemblies to be loaded manually whenever you want via System.Reflection.Assembly.Load(AssemblyName), you could have a bunch of those at the top of your Main().
Whether this really gives the effect you want is unclear though. This will cause the assembly to be mapped and the metadata parsed, but nothing will be JITed, that still happens on a mostly per method basis.
As an aside, here is the blog entry[^] I mentioned earlier about ngen.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Hi!
That gives me some hint. However, since you say nothing will be JIT'ed, it won't work for me. I have thought about adding a dummy shared method to all my classes and call them one after the other. Will the whole assembly get JIT'ed or only the dummy method will be compiled?
Thanks!
Carl
|
|
|
|
|
Even in your initially executing assembly methods are JITed on demand. Calling one method in an assembly does not force the rest to be JITed.
I suspect you are chasing a bit of a phantom here - how do you actually know that forcing your assemblies to be loaded and compiled at process creation is actually what you want? Like all performance matters, the only answer is to measure - guessing what will improve performance without profiling is extremely prone to error.
--
-Blake (com/bcdev/blake)
|
|
|
|