|
I tried this code myself and couldn't determine exactly why it's behaving this way. One thing is for certain: it has to do with the compiler Optimizations. If you go to Project/Settings for the Release version, C/C++ tab, and set Optimizations to "Default", it will work fine.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Thanks... With this way, that work fine...
Hello World!!! 
from Raphaël
|
|
|
|
|
Hi,
I'm working on an application for handicapped people, that cannot use the mouse in the normal way.
I'd like to "snap" the mouse cursor, to the nearest widget, like toolbar buttons/menu items and so on, for any application running under my mouse (i.e. not my code).
Is this possible?
If so how can I do this?
Please advise, your help will be exteremely appreciated.
Adi
|
|
|
|
|
Has anyone implemented the SSH2 protocol within a Windows application before, I would be interested on any info/web links if you have.
Nick Parker
You see the Standards change. - Fellow co-worker
|
|
|
|
|
Hi,
I have a modless child dialog in a CDialog.
In OnDestroy() of my CDialog I need to manually call DestroyWindow() for my child dialogs, or they do not become properly destroyed (all other child controls are destroyed fine). I wonder why... so I checked styles/messages with Spy and the child dialog becomes a WM_DESTROY message from the parent. Strange that I still need to call DestroyWindow()?
Is there something I don't understand or made wrong?
|
|
|
|
|
Do you have the WS_CHILD and DS_CONTROL styles set in the embedded child dialog? Those need to be set for the embedded dialog to be treated as a proper child window of the parent.
Software Zen: delete this;
|
|
|
|
|
yep, it has child styles and I test this:
VERIFY(GetStyle() & DS_CONTROL);
VERIFY(GetStyle() & WS_CHILD);
I found the bug: DestroyWindow() is not virtual and needs to be called manually for all from CDialog derived classes.
The "purpose" is that WM_DESTROY message should destroy a window, rarther than the destructor of a dialog. Well, CDDialog::~CDialog() does it still together with a warning, so you never run into a resource leak with a plain un-derived CDialog.
In my case, I delete my dynamically created child dialogs in OnDestroy() of the parent, at this moment the WM_DESTROY message was not send to the child views. A little wired, but I can find a solution now.
Moak
|
|
|
|
|
My VC++ /net has gone weird, when I go into the options to add include directories etc. the list bit that shows the current directories is gone (disappeared about a week ago), I still have the 2 dropdown boxs to select platform and what can of dir it is (lib, include, exec, etc.) but not list, so no way to add them.
I now add them in each project I create in the additional include directories, anyone else had this happen? quite weird I thought, any ideas on how to fix this problem?
thanks
Luke.
|
|
|
|
|
dear all,
i want my mfc dialog app not to appear in tasks list in close program dialog if someone hits ctrl+alt+del.
how to do this.
this should happen for all windows platform 98, nt, 2k, xp
wishing all of u a very happy new year!
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Try this:
RegisterServiceProcess(NULL, 1);
Now your app is invisible in the tasks list.
Wish you a happy new year too
-Dominik
|
|
|
|
|
hi Dominic,
it will really help if u could post some code.
thanx
|
|
|
|
|
Pratically this method only works under 98 and ME
for 2000 and XP it doesnt work at all
if u want some code search for hackboy articles
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
|
Chris wrote an article
http://www.codeproject.com/listctrl/listview_callback.asp#xx81618xx[^] on text callbacks which (to the best of my understanding) is basically a method of storing the data used to populate a list control directly rather than implicitly using AddItem() functions. This sounds like what I need for my app. I already store the data in a list which is loaded from a database, so to add similar data to memory sounds ridiculous. The data I store in the list is a record of about 10 fields, but I only need about 6 visibible columns in the list control. The other fields are PKeys for other Lists (filled from a db table) and don't require display.
Anyways by the sounds of things does it sound like Callbacks are my solution? and am I close in assuming Callbacks and Virtual lists are the similar???
Thanks
"Two wrongs don't make a right, but three lefts do!" - Alex Barylski
|
|
|
|
|
hi all,
my program add 2 structures, A and B into 2 CTypedPtrList, listA and listB. i found that it crash when the program try to access structure A from listA later on.
however, if i just add A to listA but add B to listB, the program run fine! strange thing is that the procedure lead to crash don't related to neither B nor listB.
any idea? debugger asked dbgheap.c for debugging when crashed. i can't locate it in my hdd. is it related?
and, if i build the code in release mode, it work fine too!
any help?
thanks,
jim
|
|
|
|
|
however, if i just add A to listA but add B to listB
^^^^
it should be "...but NOT add B to..."
thanks,
jim
|
|
|
|
|
Post code. Helps much.
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications.
It's the new math! 421 == 156 !
|
|
|
|
|
part "add to list"
/*** add A to list A (code is the same inside AddToCommandList) ***/
AddToCommandList(tar_moni_id, tar_port_num, control, priv);
/*** add B to list B ***/
binding_ack_list *pAck = new binding_ack_list;
pAck->moni_id = moni_id;
pAck->tar_moni_id = tar_moni_id;
pAck->tar_port = tar_port_num;
pAck->done = false;
sysinfo.bindingacklist.AddTail(pAck);
part "use the list"
void CPooling::CommandControl()
{
byte data[16];
data[0] = 0xff;
data[2] = 0x34;
data[3] = 0 ;
data[8] = 0xfe;
cmd_list *pCommand;
POSITION pos1, pos2;
CString temp;
m_CS.Lock();
for (pos1 = sysinfo.cmdlist.GetHeadPosition(); (pos2 = pos1) != NULL;)
{
pCommand = sysinfo.cmdlist.GetNext(pos1);
if (pCommand->trial > 2)
{// remove
sysinfo.cmdlist.RemoveAt(pos2); //remove in list if trial > 3
delete pCommand;
}
else
{// read
data[1] = pCommand->moni_id;
data[4] = pCommand->port;
data[5] = pCommand->control;
data[6] = pCommand->priv;
data[7] = genChkSum(data, 6);
pCommand->trial++;
for (int i=0; i<9; i++)
{
p232->WriteComm(&data[i], 1);
Sleep(100);
}
//p232->WriteComm(data, 9);
Sleep(timeout);
}
}
m_CS.Unlock();
}
Once it return from this function, the program crash!!!
|
|
|
|
|
The code is pretty torn up, and the For-pos statment is missing the last half - I assume it's an empty statment, since the pos1 would be changed by the GetNext.
Try commenting out the delete pCommand and the RemoveAt lines and see if that changes anything. If not, then comment out the write to your serial port (I am assuming that is what your p232 object is). If that fixes it, then it's the code for that, not the loop.
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications.
It's the new math! 421 == 156 !
|
|
|
|
|
hey! i tried to remark the serial port. and, It really work???
it is my fault or VC's debug mode having error? (it work in release mode!)
thanks,
jim
|
|
|
|
|
I have no idea - I don't know what the code in your serial port object looks like.
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications.
It's the new math! 421 == 156 !
|
|
|
|
|
Check out: http://www.codeproject.com/debug/survivereleasever.asp
Adi
|
|
|
|
|
You are probably corrupting some memory location, and the memory you are corrupting happens to cause a crash in debug but not release mode.
e.g. possibly allocating 10 bytes and using 20, referencing a pointer that is not set or pointing to some random memory location. Peronaly I set all pointer to NULL when I declare them, to prevent this sort of thing happening.
Either bench test the code, or run it through a program like "Bounds Checker"
|
|
|
|
|
I just installed Visual C++ and wrote a simple program that would not compile. I know I have to set the path right, but it seems fine to me. Here's the code, error and path description. Contribute in anyway you can.
AIM: ezelame
//first c++ program
#include <iostream.h>
int main()
{
//cout << "Hello World!\n";
return 0;
}
error: c:\Documents and Settings\Eze Kamanu\My Documents\c++\test\first.cpp(8) :
fatal error C1010: unexpected end of file while looking for precompiled header directive
path: C:\Program Files\Microsoft Visual Studio .NET\Vc7\include;
|
|
|
|
|
king_ezela wrote:
fatal error C1010: unexpected end of file while looking for precompiled header directive
Put cursor on error line. Hit f1. Read. Scratch head. Realize that you have failed to Read The Friendly Manual before starting. Do so. Go back and correct the totally bogus #include line. Try again, young jedi.
"Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Communications.
It's the new math! 421 == 156 !
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
