|
Not exactly (other than what is shown here), but I've e-mailed Dr's Russinovich and Cogswell in the past and they have been helpful. They obviously don't give away trade secrets, but if something is available and it is just rather hard to find, it shouldn't be a problem. They might even point you to one of their books.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
"On Windows NT the heart of Filemon is a file system driver that creates and attaches filter device objects to target file system device objects so that Filemon will see all IRPs and FastIO requests directed at drives."(http://www.sysinternals.com/ntw2k/source/filemon.shtml):
also known as File System Filter Driver (Hook)!
Don't try it, just do it! 
|
|
|
|
|
And you sent this to me because?? I know what their site says, which is why I referenced it in my reply. If that paragraph is a good enough description of what is going on, fine. If not (which I assumed was the case), contacting the author(s) is the way I'd go.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I've ben pondering your sig for a while now.
Either you're tricking me - or there's something I'm missing 
would "two birds" be an inappropriate answer?
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
mlog || Agile Programming | doxygen
|
|
|
|
|
peterchen wrote:
would "two birds" be an inappropriate answer?
decided to fly away != actually did fly away
I got caught by that too. 
The kindest thing you can do for a stupid person, and for the gene pool, is to let him expire of his own dumb choices.
[Roger Wright on stupid people]
We're like private member functions
[John Theal on R&D]
We're figuring out the parent thing as we go though. Kinda like setting up Linux for the first time ya' know...
[Nitron]
|
|
|
|
|
Hello!
How is the memory allocated when using new? The problem is that I have to allocate many single entries which are very small and I don't know now how that will affect memory consumption and speed.
For example:
Will
int i;
for(i = 0; i < 1000; i++)
p[i] = new DWORD[1];waste much memory than if I would use
p = new unsigned char[4000]; Actually the entries aren't that simple and the code above should be meant just as an example. If I want to allocate lets say 16 bytes, does the memory allocation routine round that number up somehow and allocate more than I need?
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
i don't know how it is alloced, it's heap memory, so prolly by malloc.
use the debugger and follow the new call to find out, how it works!
Don't try it, just do it!
|
|
|
|
|
The first example will eat *much* more memory than the second.
Heaps are typically organized as a list of memory blocks that are either used or available. Since you might want to free the allocations in the first example individually, it needs to keep some extra information for each allocation.
The first one can slow down a program considerably, first because of memory footprint, second because searching for a matching free block takes longer (because there are much more blocks to look at). Many allocations of that small size are not recommended from the normal heap.
However, you can use a custom allocator that better fits your needs.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
mlog || Agile Programming | doxygen
|
|
|
|
|
Ok, thank you  Then I will have to do some sort of custom allocator.
Dominik
Btw: der Link zum Agile Programming tut nicht mehr direkt
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
Dominik Reichl wrote:
If I want to allocate lets say 16 bytes, does the memory allocation routine round that number up somehow and allocate more than I need?
Yes.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hi guys,
I can't believe how much hassle I'm having trying to trap a user's confirmation of a CEdit entry. I have a toolbar with a CEdit control on it. Ideally the user should only input numbers.
What's the best strategy to catch the obligatory ENTER confirmation? I create the toolbar and CEdit control in CMainFrame, but CMainFrame doesn't get any of the key notifications.
Any ideas?
Many thanks,
S
Multimedia programmer, trying to learn a grown-up language!
|
|
|
|
|
Do you get the key notifications in PreTranslateMessage of your CMainFrame before they go to the edit control etc. If you do, you can trap and process them there.
Roger Allen
Sonork 100.10016
Death come early, death come late,
It takes us all, there is no reason.
For every purpose under heaven,
To each a turn, to each a season.
A time to weep and a time to sigh,
A time to laugh and a time to cry,
A time to be born and a time to die.
Dust to dust and ashes to ashes,
And so I end my song.
|
|
|
|
|
Thanks Roger, that worked great.
Multimedia programmer, trying to learn a grown-up language!
|
|
|
|
|
#include "ColourSelection.h"
ect. until
void CProjectView::OnInitialUpdate()<br />
{<br />
CFormView::OnInitialUpdate();<br />
GetParentFrame()->RecalcLayout();<br />
ResizeParentToFit();<br />
ChangeColour();
<br />
}<br />
<br />
void CProjectView::ChangeColour()<br />
{<br />
CColourSelection *pSelector = new CColourSelection(this);<br />
pSelector->Create(CColourSelection::IDD, this);<br />
pSelector->ModifyStyle(0,WS_VISIBLE);<br />
delete pSelector;<br />
Invalidate();<br />
}
I can't understand why the dialog box ISN'T opening
Anyone has any knows the correct code or what is the bug in my code?
|
|
|
|
|
Alton Williams wrote:
delete pSelector;
You are destroying immediatly the dialog box you have created. Destroy the object in CColourSelection::PostNcDestroy instead.
void CColourSelection::PostNcDestroy()<br />
{<br />
delete this;<br />
}
Silence Means Death
Stand On Your Feet
Inner Fear
Your Worst Enemy
|
|
|
|
|
KaЯl wrote:
Destroy the object in CColourSelection::PostNcDestroy instead.
I've tried that but dialog is still not opening.
KaЯl wrote:
void CColourSelection::PostNcDestroy()<br />
{<br />
delete this;<br />
}
I want to extract values from dialog object priorto destruction in my CFormView class. Hence, it's not appropiate for CColourSelection to "commit suicide".
|
|
|
|
|
Alton Williams wrote:
I've tried that but dialog is still not opening
You have also to call pColourSelection->ShowWindow(SW_SHOW);
Are you sure the problem doesn't come from your CColourSelection class?
Alton Williams wrote:
Hence, it's not appropiate for CColourSelection to "commit suicide".
It's not exactly a suicide. The PostNcDestroy method is called after the destruction of the dialog box (destruction != deleting). This method allows to free the memory you've allocated with the new CColourSelection.
Check your mail, I've send a small app showing the use of a modeless dialog.
HTH,
K.
Silence Means Death
Stand On Your Feet
Inner Fear
Your Worst Enemy
|
|
|
|
|
How do I make them disappear...
I've tried:
cs.dwStyles = ~ WS_VSCROLL;
But it causes the framework to not create a document or something like that...
Any ideas how I can go abouts doing this...?
Thanks
Cheers
I'm drinking triples, seeing double and acting single 
|
|
|
|
|
Are you sure the scrollbars are carried by the CMDIChildFrame, and not by the embedded view contained in the Child Frame?
What kind of view do you use?
Silence Means Death
Stand On Your Feet
Inner Fear
Your Worst Enemy
|
|
|
|
|
1. I have a simple dialog window, which has the "minimize" box enabled; the "maximize" box is not enabled.
2. One of the buttons of my mouse is customized as "maximize". Pressing this button maximizes the above, "non-maximizable" window.
Is there a direct, clean way to prevent this maximizing? I guess posting a WM_SIZE message with SIZE_RESTORED from OnSize would work, but I find it strange that a "no" won't be taken as "no".
|
|
|
|
|
Catch the WM_SIZE:
OnSize( UINT nType, int cx, int cy );
if nType==SIZE_MAXIMIZED don't let the message go further.
Mickey
|
|
|
|
|
Thanks; however this does not help. The OnSize description states:
The framework calls this member function AFTER the window's size has changed.
I fact, this filtering in OnSize does not change the result. A call of CDialog::OnSize will be generated by the wizzard in OnSize. I admit that I don't know, what CDialog::OnSize does (this will be generated by the wizzard in OnSize), but no matter if I call it or not, the result is the same.
In the meantime I tested my own suggestion, posting a WM_SIZE message with SIZE_RESTORED. This does not work either; I'd like to know, why. The message goes through properly, it appears in OnSize as well, with the identical parameters, as a RESTORE from the minimized state generates - but restoring does not happen.
SetWindowPlacement works, but that needs more preparation: not only the size, but the position of the last non-maximized window too has to be recorded. Not a big deal, but all this is nonsense.
|
|
|
|
|
Have you tried to catch WM_WINDOWPOSCHANGING[^]?
Silence Means Death
Stand On Your Feet
Inner Fear
Your Worst Enemy
|
|
|
|
|
You must also process the CWnd::OnGetMinMaxInfo or handle WM_GETMINMAXINFO.
If that does not work, override CWnd::PreTranslateMessage and trap the sizing calls.
The memories of a man in his old age are the deeds of a man in his prime.
|
|
|
|
|
Thanks for the suggestions.
WM_WINDOWPOSCHANGING appears a good solution, but it does not say, when the window will be maximized, i.e. it would need a "calibration" to get the actual maximum size.
In the meantime I solved the problem already, with a combination of OnSize and OnMove plus SetWindowPlacement as correction of MAXIMIZE. However it is not a nice solution. Sometimes OnSize, sometimes OnMove is the first, when both will be called. Lots of work-around only to prevent the system from doing something, what it should not do per definition.
Anyway, now it's working, but I'm now trying Blake's suggestion, GetMinMaxInfo. This function gets called before each MAXIMIZE (I have expected a call at MINIMIZE at well, even though it does not matter in my case). Simply to prevent MAXIMIZE to a large size is very simple this way. However, there is still a small problem: it positions the window to the upper left corner; one has to work around it.
Once more, thanx for the help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
