|
Hello,
I want to launch a timer starting from a method which one has to declare, because I wants that a thread launches it.
of habitud the timer is launched starting from an event of click of a boutton
how to do it its without having an event of click.
Thank you,
aef
|
|
|
|
|
I am confused about what you want to do?
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
I have a beginners question. What does the code look like to use DrawLine
in C++ CLI? -- thanks
|
|
|
|
|
Here's one way:
<mshelp:link tabindex="0" keywords="T:System.Drawing.Graphics" xmlns:mshelp="http://msdn.microsoft.com/mshelp">Graphics^graphics = CreateGraphics();
Pen AzurePen(Color::Azure);
graphics->DrawLine(%AzurePen, 10, 10, 50, 50);
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
Of course, this line will disappear as soon as the form is invalidated. All drawing should occur in the paint event
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Heh! I didn't say where to put the code, nor was I asked! LOL
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Actually, IMHO, you shouldn't give too much more information than they ask for. You learn more from trying and failing (a.k.a. experience) than someone telling you as a by-the-way comment.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Also, I find the distance I drift away from what the OP really wanted is often directly proportional
to the amount of example code I type and/or copy
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Word!
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
George L. Jackson wrote: You learn more from trying and failing
Yes but this is 2007 and you will get paid more by making your deadlines using copy/paste ! We don't don't need no stinkin learnin! :->
|
|
|
|
|
Hi Mark,
your code was not targetting the paint handler, it includes a CreateGraphics(),
whereas A paint handler would hand you the Graphics to use !
Greetings
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
|
|
|
|
|
Indeed! Thanks Luc
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
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.
|
|
|
|
|
Xpnctoc wrote: The application I am writing is very dialog-intensive.
I'm confused, is that a recommended User Interface Design?
Xpnctoc wrote: Does anyone know if the GC works on a time interval or a certain percentage of consumed memory, or what?
No. Nobody knows. Not even the guys at Microsoft that developed it, documented it and then published MSDN whitepapers, articles and blogs about how it works.
Xpnctoc wrote: Thanks for your help.
No problem
[modification] Sorry forgot to mention, don't try to use google to find any information on the subject, I am pretty sure that won't work. For example none of this would help[^]
|
|
|
|
|
If you don't trust the GC, then get out of .NET coding IMMEDIATELY! You'll
never sleep!
In addition to led mike's reply...
I didn't trust the GC when I started with C++/CLI. After 15+ years of C/C++, i am
VERY used to handling allocation/deallocation myself. I had to write a bunch of test code
to convince myself it worked. Maybe that will help you?
Managed objects WILL be freed eventually once no references are left on them. If you
mix unmanaged objects in managed classes you need to make absolutely sure you're using
destructors and finalizers properly and freeing any unmanaged resources. You are still
responsible for the scope of your managed objects. If they never go out of scope, they
will NOT be cleaned up by the GC.
The task manager is NOT a debugging/development tool.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Try this with a few WinForms apps(release builds of a C# apps). Start it up and watch the memory usage in task manager. Make sure you are not running the Visual Studio host process (appname.vshost.exe). Move it around and use the menu etc. and watch the memory usage climb until you have had enough fun with that. Now minimize it. After your initial "hmmm interesting" reaction, continue watch memory usage while you restore it and manipulate it some more.
Be sure to let me know what happens!
|
|
|
|
|
|
I know it's a C++ board. I posted it here because it is a C++/CLI application, and I was wondering if anyone else had encountered this phenomenon. But then after I had posted I got around to thinking it might be a more generic .NET issue. Sorry.
|
|
|
|
|
My reply was to led mike.
You are on the right board AFAIK
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: How high does it climb? Infinitely?
Well I get bored before I have any conclusive data. No doubt there are far better methods to actually test like with a profiler etc.
So anyway this is mildly interesting I have a utility app that I use to work with XML files XPath statements etc. I initially wrote it years ago in VC++ it uses MSXML and hosts the browser for one of the views. So like a year ago or so I remade it using C#. Now the new version is slightly more feature rich from a UI perspective and you would therefore expect a larger memory footprint but all in all they are very similar.
So you start the old VC++ app and it loads in at around 14 meg. After opening a few files and manipulating the UI to view stuff etc it grows up around 18 meg and you can see it freeing memory and it settles down just over 17 megs.
The C# app loads at just over 26 megs and you can get it to climb from there. But if you minimize it it drops to 1.1 meg! Then when you restore it it jumps up to 12 meg and as you begin to work it (open files and run XPath queries, manipulate the views etc.), it climbs up to just over 18 meg and you can see it free memory back down to just under 18 megs.
So overall the C# app has slightly more bells and whistles and uses a slightly larger memory footprint once you minimize it and restore it. I have no idea what that is all about but I wouldn't expect significant memory consumption from a .NET Windows Forms app. The UI is definitely not as responsive as the native app but memory consumption I would have to say is very similar.
Oh yeah I am running XP Pro
|
|
|
|
|
I understand that some things will be held on to because they don't go out of scope. But it seems to me there are some serious problems within the .NET framework not properly releasing references. Consider the behavior of the Menu control:
Every time I click my "File" menu (just as an illustration), MORE memory is sucked up to generate the drop down (New, Open, Save, etc...). Sure, the Menu control never goes out of scope as long as the application is run, but why does it grab more memory every time? It seems to me that after the memory has been allocated once, that should be the end of it. If I call up the "File" menu a second time, there should be no reference left to the original fly-out. The memory consumption should stay constant because one reference was destroyed and one was created. But no. The framework sucks up the additional memory to create a new reference without reliquishing the old reference.
As many times as I expand any menu item, more memory is consumed. None is ever reliquished. And, as I stated in my original post, I took my unmanaged data out of the equasion. I'm talking about just running an application form with a menu system -- before I do any of the real application work or allocate any of the core data structure memory.
If .NET won't release any of the consumed Menu memory before application termination, then I might as well go back to VS6. That's just too sloppy.
|
|
|
|
|
AFAIK, the GC will kick-in whenever it feels like working or when a low memory situation. In my little world, I have never had a .NET application run out of memory that they gobbled up!
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Like I mentioned to led mike, I don't use .NET GUI so I can't comment on the
specifics of your situation..
If I remember correctly from my tests, in an infinite loop allocating objects on the managed heap
and watching in the task manager, memory use would climb to around 300MB between each cleanup
by the GC. That was VS2003/.NET 1.1. Strangely, I cannot replicate that with VS2005 LOL
I'm trying to make an infinite loop that allocates and the memory never moves.
If you need to keep everything cleaned up immediately, Does GC.Collect() help?
If this stuff leaks why isn't everyone screaming about it? I would think by now
someone would have noticed. .NET would indeed be useless.
Cheers!
MArk
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Also, you can minimize memory usage in .NET by cutting back in the creation of mulitple or temporary small objects. For example, instead of doing a lot of string manipulations on a String , use a StringBuilder object instead.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|