|
No. It's called Visual C++.
|
|
|
|
|
Realistically, the only way a .NET application can run is if the correct version of the .NET Framewowrk is installed on the target computer. You can still run a .NET application as part of a CD's autorun, but it will still depend on having the .NET Framwork already installed (or you will need to install it yourself before your application runs).
|
|
|
|
|
|
plz can someone help me to get a FREE version of infragistics NetAdbantage for .Net from onother source of "www.infragistics.com" ?
|
|
|
|
|
So, what made you SPAM the forums with 7 copies of this question? It's considered very rude to do so and make collaboration on an answer pretty much impossible.
This[^] is the only place you're going to get the trial version.
|
|
|
|
|
Especially when it seems like he is spamming for a free pirated version...
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Yeah, he posted another question, and the spamming continues. Some people just never listen, not even to the answers you give them.
|
|
|
|
|
Dave Kreskowiak wrote: Some people just never listen, not even to the answers you give them.
Either they are really dense or just a stupid bot.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Paul Conrad wrote: they are really dense or just a stupid bot.
Adamant attitude. They feel that repeated pings should convince at least some one to succumb to thier 'Mission Piracy '.
|
|
|
|
|
Vasudevan Deepak Kumar wrote: 'Mission Piracy'
Could always be that.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
|
how do you add a custom component to the toolbox?
I have created a custom control in .net 3.0 and i
can't add it to the toolbox.
thank you...
-- modified at 17:38 Sunday 26th August, 2007
It Is Not That I'm Different!
... I'm Only Making The Difference!
|
|
|
|
|
ferdna wrote: can't added i to the toolbox
What is the error? Shouldn't be any different than anything else being added to the toolbox.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
i don't get an error at all... VS crashes when i drop the component into the form..
thank you
It Is Not That I'm Different!
... I'm Only Making The Difference!
|
|
|
|
|
ferdna wrote: VS crashes when i drop the component into the form..
Hmmm, that's odd.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Hello,
I posted the following in the C++/CLI forum, because the application I was writing when I noticed the problem is written in C++/CLI. However, the thought occured to me that maybe this is something .NET developers in C# or VB.NET have also experienced. Please take a read through and let me know what you think. Thanks!
Yesterday I tried an experiment.... I took a C++/CLI application of mine and disabled my menu-disabling code so that my full menu system (with fly-outs) would work even when no application data was open. Using Task Manager to monitor my memory use, I noticed that every time I expanded a top-level menu or moused over a sub-menu that triggered a fly-out, more memory was used. No shock there. BUT, when I click back in the main window area to make all the fly-outs disappear, the memory use does NOT decrease! In fact, I sat there for 10 minutes waiting for Task Manager to show some drop in memory use, but it never did. Meanwhile, when I triggered the same fly-out again, even MORE memory was used.
I noticed the same behavior when I triggered the Open File Dialog (.NET out of the box -- no overrides or anthing weird).
The application I am writing is very dialog-intensive. The base application uses about 64MB. But at the consumption rates I'm seeing, I could very well imagine that after an hour or so I'd be up to 512MB from invoking dialogs and the GC failing to reclaim memory.
What the heck is going on? Is my Garbage Collector broken? Should I somehow manually invoke garbage collection to clear some memory? Does anyone know if the GC works on a time interval or a certain percentage of consumed memory, or what?
Thanks for your help.
|
|
|
|
|
Hi,
you may not have a problem at all.
when you instantiate some class, an array, a dialog, whatever, you would need more
memory; either your Operating System allows you that, or your gc will try and free
up some of the memory that is already yours. There is nothing periodic about it,
it's on a need-to-run base.
So if your app is allowed 100MB, it will grow until it starts to reach such numbers,
only then will gc run, and you may fall back to as low as a few MB. Who cares ?
If the number it falls back to keeps growing, then there is a potential problem,
since that indicates more and more objects don't get freed, either because you
really need more and more objects, or because you have a memory leak.
If you are not using unmanaged code, the typical way to get memory leaks is by
forgetting to call Dispose() for objects instantiated from a class that has such
method. There are many, one that people often seem to forget is Form (and hence
also OpenFileDialog). For dialogs, you should create and show them, then
collect the results and dispose.
Hope this helps.
BTW: there are lots of articles on memory, dispose and the like, here on CP and
elsewhere.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
So in other words, I'm paranoid.
The application I'm writing requires a potentially unlimited amount of user data. Well of course this is impossible because a computer only has a finite amount of memory. But what I've been worried about is that someday I'll be using the app and I'll hit memory capacity because the GC didn't reallocate 100MB+ that was used up in temporary dialog boxes in menus. But if it's just because the GC is lazy and doesn't kick in until absolutely necessary, then I guess I should be OK.
|
|
|
|
|
Well, that doesn't exactly guarantee you won't run out of memory. You can still cause leaks, like resources and handles. For example, with all these dialogs, are you showing them by calling .ShowDialog() ?? If so, are you then calling .Dispose() on those dialogs when you're done with the data in them?? If not, you'll eventually run the system out of resources and cause an OutOfMemory exception.
|
|
|
|
|
Hey, I though that a code
openFileDialog.ShowDialog();
openFileDialog.Dispose();
openFileDialog.ShowDialog();
throws "object disposed" excpt or sth like that, doesn't it? So if I use this dialog all the time...
Greetings - Gajatko
|
|
|
|
|
of course you only dispose of things you don't need any longer.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
gajatko wrote: So if I use this dialog all the time...
You create a new instance of it...
|
|
|
|
|
Hi,
there are good reasons why the gc is lazy, and should not be called explicitly:
1. it is an expensive operation, since it needs to check all the data in your app, figuring
out which objects still have references to them (are "alive") and which don't. There can
be a lot of data involved, it does not fit in the cache, and it trashes the cache
(i.e. whatever was rightfully in there now is gone).
2. while doing its job, the gc suspends all your threads, to make sure the stacks
and objects don't change while it is examining them; so your app is temporarily dead.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Xpnctoc wrote: Using Task Manager to monitor my memory use,
Stop right there. You're looking in the wrong place. Managed code (.NET CLR) apps run inside a virtual machine, just like a Java app. What Task Manager is showing you is the RAM reserved for the entire virtual machine your app is running in, not just your app. So, even though your app isn't using that memory, it's still being held by the virtual machine for future use. That's why the memory doesn't get freed.
Xpnctoc wrote: Is my Garbage Collector broken?
Nope. It's just being lazy. It will hang on to that memory, so long as Windows doesn't want it back. When Windows starts to get low on memory, it'll ask the virtual machine to release whatever it can back to Windows.
Xpnctoc wrote: Should I somehow manually invoke garbage collection to clear some memory?
This won't solve the "problem". This will tell the GC to free up any managed memory that hasn't already been freed. But, this memory goes back into the Managed Heap (reserved for future use), NOT back to Windows.
Xpnctoc wrote: Does anyone know if the GC works on a time interval or a certain percentage of consumed memory, or what?
The GC is extremely good at it's job and runs whenever it detects the need to. There is no set schedule and it tunes it's own performance based on how it sees your app running and what it expects your app to do in the future.
|
|
|
|
|
Thanks for the insight, Dave. I have never heard that .NET was actually running on a virtual machine. I knew there was JIT and such involved, but that puts things into a little different perspective.
And like I told Luc, I think I'm coming to the realization that I'm just paranoid because of the extreme data memory requirement of the app I'm writing. But I'd even take it one step farther and suggest to myself that I'm also only working in the theoretical, because it would take a long time using the app to develop the need for so much memory.
By then we'll probably be talking terabytes of memory on standard computer models anyway
|
|
|
|