|
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)
|
|
|
|
|
Dear All,
I wanted to know whether there is a way to solve this problem or not?
The problem is as I describe it here:
There is already a program written and it has to access a directory which the user working with this program does not have access. I know how to set an impersonation context in a program I (I mean I) am writing. But the problem here is that this program is already written and compiled and I do not have access to source files to add this impersonation solution to the source code. So I need a way to change the user which is logged in toa user that has access to that folder and run the program in a way that impersontion context is copied for that program so this program can use iot to access the folder.
Please help me through this problem.
Thanx Alot
|
|
|
|
|
Sounds like P/Invoke time. Read up on LogonUser and CreateProcessAsUser on MSDN.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Or CreateProcessWithLogonW()which is easier.
Mazy
No sig. available now.
|
|
|
|
|
Good catch, assuming it doesn't need to run on NT4 - which one would hope is getting to be a safe assumption these days.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
According to MSDN both are the same except seconnd on one need W2K ot higher and it is easier to use.
Mazy
No sig. available now.
|
|
|
|
|
Hi,
Please look at the code and let me know the error !
System.Reflection.Assembly thisExe;
thisExe = System.Reflection.Assembly.GetExecutingAssembly();
string[] t = thisExe.GetManifestResourceNames();
foreach (string s in t)
{
System.IO.Stream str = thisExe.GetManifestResourceStream(s);
Console.WriteLine(str.GetType().ToString());
}
The result is :
"System.IO.__UnmanagedMemoryStream" for all resources.
Why ? Any suggestions ?
Paul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
