|
Strange, it should.
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]
|
|
|
|
|
I know that its strange
|
|
|
|
|
I mean the origina posted code was wrong.
On the other hand, if you're still experiencing memory leaks, probably there's a problem elsewhere. Does the dump of the memory block give you any insight?
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]
|
|
|
|
|
The place of the leak is there - i check it be return in the first line of the method - and its does not give me the leak.
the dump mem deos not help.
|
|
|
|
|
Why do you assume that all fo the three input arrays have the same size?
What do the arrays contain (i.e. what are the actual parameters of the call)?
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]
|
|
|
|
|
So where is the correspond OleUninitialize ?
system
|
|
|
|
|
Inside AfxPostQuitMessage , called for instance in the WM_NCDESTROY message handler.
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.
I'm getting this warning in my project:
warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
This is the code:
(...)
char resp;
while(op_back!=2)
{
(...)
if(A !=0)
{
do
{
(...)
cout<<"Do you want to modify this object? [Y/N] ";
fflush(stdin); cin>>resp;
resp=toupper(resp);
}while(!(resp=='Y' || resp=='N'));
if(resp=='Y')
{
(...)
Is there an easy way to resolve this warning?
And another warning:
warning C4310: cast truncates constant value
gotoxy(0,1);cout<<char(218);
Thank you!
Thank you
"Failure is always an option."
|
|
|
|
|
What compiler are you using? I can't get any warnings
out of any of that code.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I'm using visual c++ 2008 express edition. The warning levels are at max level (4) ...
This is a uni project.. do you think i should put it back at level 3? Is this warning relevant?
"Failure is always an option."
|
|
|
|
|
FrankMookie wrote: This is a uni project
What is a uni project? Do you mean unicode?
|
|
|
|
|
No.. it's an university project.
"Failure is always an option."
|
|
|
|
|
|
FrankMookie wrote: Is there an easy way to resolve this warning?
Yes:
resp=(char) toupper(resp);
FrankMookie wrote: Is there an easy way to resolve this warning?
And another warning:
warning C4310: cast truncates constant value
gotoxy(0,1);cout<<char(218);
What do you intend to do (as you know char's range is [-128,127] )?
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]
|
|
|
|
|
What about the extended ASCII table? the rage goes to 255 http://www.asciitable.com/[^] .
But I did the experience of changing the "218" to a number between the normal range.. and the warning disapeard.
So.. that means i shouldn't use the extended range?
"Failure is always an option."
|
|
|
|
|
Well char is a C/C++ integer data type whoose range is [-127,128] while the extended ASCII table is (roughlty) simply a standard about encoding characters using (8-bit ) numbers.
Anyway, I made a little test: you may use
cout << unsigned char(218);
to the purpose.
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]
|
|
|
|
|
Great.. the warning does not appear anymore.
Thanks allot!!
"Failure is always an option."
|
|
|
|
|
You're welcome.
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]
|
|
|
|
|
Please consider the following fragment of code from the book Programming Windows 95 with MFC
by Jeff Prosise:
CMainWindow::CMainWindow()
{
CString strWndClass = AfxRegisterWndClass ( 0, myApp.LoadStanddadCursor ( IDC_ARROW ),
(HBRUSH)(COLOR_3DFACE + 1), myApp.LoadStandardIcon( IDI_APPLICATION ) );
I do not understand why is is COLOR_3DFACE + 1, instead of COLOR_3DFACE. Since COLOR_3DFACE represents an enumeration value, it seems to me, adding 1 to it is wrong. What am I missing?
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: why is is COLOR_3DFACE + 1, instead of COLOR_3DFACE
Because the docs state that's the way it needs to be:
WNDCLASS.hbrBackground
Handle to the class background brush. This member
can be a handle to the physical brush to be used
for painting the background, or it can be a color
value. A color value must be one of the following
standard system colors (the value 1 must be added
to the chosen color).
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark's answer is the good one.
The following is just a guess on the motivation:
Possibly because it avoid the following conflict
(from Winuser.h )
#define COLOR_SCROLLBAR 0
(from MSDN on WNDCLASS.hbrBackground )
When this member is NULL, an application must paint its own background whenever it is requested to paint in its client area.
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]
|
|
|
|
|
Sorry, I'm quite angry with this problem ...
I tried to code a system-wide keyboard hook and send recived keyboard messages within a DLL toward an EXE ...
Everything went fine but TranslateMessage() that fails to generate WM_CHAR ...
within DLL:
------------------
struct lParamMember
{
WORD RepeatCount : 16,
ScanCode : 8,
IsExtended : 1,
Reserved : 4,
IsALTDown : 1,
WasKeyDown : 1,
IsBeingReleased : 1;
};
LRESULT CALLBACK KeyboardProc(int iCode, WPARAM wParam, LPARAM lParam)
{
if(iCode<0)
return CallNextHookEx(hKybrdHook, iCode, wParam, lParam);
lParamMember* plParam = (lParamMember*)&lParam;
if(plParam->IsBeingReleased)PostThreadMessageW(g_dwThreadID, WM_KEYDOWN, wParam, lParam);
else PostThreadMessageW(g_dwThreadID, WM_KEYUP, wParam, lParam);
return CallNextHookEx(hKybrdHook, iCode, wParam, lParam);
}
withing EXE:
-------------------
MSG msg;
while(GetMessageW(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
if(msg.message == WM_CHAR || msg.message == WM_DEADCHAR || msg.message == WM_SYSCHAR ||
msg.message == WM_SYSDEADCHAR)
MessageBox(0, L"Success!", 0, 0);
}
----------------------------------------------------------------
|
|
|
|
|
Jusef Marzbany wrote: if(plParam->IsBeingReleased)PostThreadMessageW(g_dwThreadID, WM_KEYDOWN, wParam, lParam);
else PostThreadMessageW(g_dwThreadID, WM_KEYUP, wParam, lParam);
Are these switched? I thought releasing a key meant keyup, not keydown.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I did as you, but it still doesn't work ...
Now it looks like this:
-----------------------
if(plParam->IsBeingReleased)PostThreadMessageW(g_dwThreadID, WM_KEYUP, wParam, lParam);
else PostThreadMessageW(g_dwThreadID, WM_KEYDOWN, wParam, lParam);
Help me PLS
|
|
|
|
|
Disclaimer: I'm only trying to help find potential problems
with the info given. Don't assume I know the solution - I don't.
Emulating system messages is always problematic.
What's happening in the debugger?
To start with, are your WM_KEY* messages actually getting to
the EXE's message loop?
Next, maybe take a look (using the debugger) at the sequence of
messages involved with a real keystroke. You're going to need
to emulate that exactly for this to work.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|