|
MKC002 wrote: It gives me wrong information like drive start address, size etc
Are the values just outright garbage, or maybe just some other power of 2 (e.g., 512 instead of 1024)?
What does DeviceIoControl() return?
What are you using to compare these "wrong" values against?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Has the disk got one or more mounted partitions sitting on top of it? If it has try unmounting those first and see if the IOCTL you want to use starts working. Vista added the restriction that you couldn't read and write to a disk when it has mounted file systems and this might be more of the same.
Cheers,
Ash
|
|
|
|
|
In List control, while using the Scroll bar, how we can know how much rows has went upside if scroling.
Thanks
|
|
|
|
|
guessing that the list control is in report view,
try handling LVN_ENDSCROLL notification from List control. Use GetTopIndex() to get the index of top visible item. That much rows will be on top.
|
|
|
|
|
You may use the CListCtrl::GetTopIndex, I suppose.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi!
Should I delete the pointers that are not allocated using new? While running my application, it crashes, displays the following exception:
Unhandled exception at 0x00509260 in SlogOut3D.exe: 0xC0000005: Access violation reading location 0xcdcdcdcd.
and exception pointer moves to this line:
gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
The above line is inside the constructor. Should I delete gui::IGUISkin* skin?
modified on Friday, September 3, 2010 4:36 AM
|
|
|
|
|
That looks like you're trying to use an uninitialised object of some sort.
And you only ever use delete when:
- you've newed an object
- the API you're using says you delete objects it supplies
In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Cheers,
Ash
|
|
|
|
|
Aescleal wrote: In both cases use a pointer class to manage your memory though to reduce the complexity of your code.
Can you please be a little bit exact on what I should do?
|
|
|
|
|
T.RATHA KRISHNAN wrote: Should I delete gui::IGUISkin* skin?
Normally not but you have to check what is said in the documentation.
But anyway, it seems the problem is elsewhere: did you use your debugger to see if device was created properly ? Check also the return of getGUIEnvironment and the return of createSkin.
|
|
|
|
|
T.RATHA KRISHNAN wrote: gui::IGUISkin* skin = device->getGUIEnvironment()->createSkin(EGUI_SKIN_TYPE::EGST_WINDOWS_METALLIC);
How CreateSkin internally creating the object!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
what is data Serialization in MFC framework
|
|
|
|
|
Instead of writing a long description here, I suggest you take a look at this article[^] (it's part of a series of 3 articles that fully cover the subject).
|
|
|
|
|
In addition to Cédric reply, you may have a look at official documentation too "Serialization in MFC"[^] (if I remember well, isn't bad).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi all,
i m working on MFC SDI type application,when i change my DPI Settings to 120 than all application forms looks bigger than its actual size but all are properly displayed here,scrollbar is display if form is looks more bigger.
my problem is that when i saw a print preview and here Zoom the view at its maximum point and than close the print preview window now the form is display more bigger and controls are not properly displayed here.
please help me what can i do here.
thanks in advance.
|
|
|
|
|
Maybe your GDI mapping mode got changed from MM_TEXT to something else during print preview. I noticed when I used Visual Studio 2010 project generator and specified a CFormView-based class, it warned me that the printing would automatically be disabled, so there must be some funky incompatiilbity in there. I do not know what the real problem is, but based upon how you said things got all wierd, the mapping mode would be my first guess.
|
|
|
|
|
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore).
I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory.
I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
|
|
|
|
|
Sorry i can't answer your actual question, since i don't know what cool memory leak detection ways there are but i not so long ago we ran into some memory-fragmentation problems with our projects and we had to dig a bit deeper into memory management to cope with it and we leartn a few new things.
You might be experiencing slight memory usage increase because -as far as i know- CRT doesn't always "physically" free up memory when you call delete/free, it preserves some amount so it can quickly reuse it when new allocations are needed, i think it mostly does that for smaller allocations because it is more efficient that way, am not sure how you could test if this is the case or not though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I thought that too, but I wrote a small test app which did a bunch of new ops then, when requested, freed them all.
What I noticed was that (when viewing these columns in Process Explorer) the virtual size never dropped back down. It just stayed where it was after all the new calls. But, the private bytes and working set did drop right back down after freeing the memory. And its these 2 columns where I'm seeing the persistent growth.
I check the memory usage, then load the data, the free it all, then check again and repeat this multiple times with the same instance of the app. Each time I get a growth in those columns.
|
|
|
|
|
|
About Visual Leak Detector, you'd better try the most recent versions @ codeplex : http://vld.codeplex.com/
(pre-emptive WTF, the clicky thing stopped working in Safari?!?!)
Watched code never compiles.
|
|
|
|
|
Thanks for the links! I'll take a look at those.
|
|
|
|
|
The best approach isn't to leak any memory, then you don't have any leaks to find. So instead of using raw pointers use a wrapped pointer of some sort, instead of dynamically allocated arrays use std::vector. The moral is if you don't manually manage it you can't leak it.
Cheers,
Ash
|
|
|
|
|
of course
|
|
|
|
|
Aescleal wrote: The moral is if you don't manually manage it you can't leak it.
Where's the fun, then (OK I didn't notice it was a 'moral'...).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You can also try Microsoft's Application Verifier.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
