C / C++ / MFC

Christian Graus15-Jul-02 12:31

15-Jul-02 12:31

You've traced this through and sInput does indeed contain the word 'connect' ???

Why are you using a BOOL instead of a bool ?

Personally I'd also include a timeout in code like the above. What if m_Comm.GetInBufferCount() remains 0, or sInput.Find("connect") continues to be -1 ?

Christian

come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Frank Deo15-Jul-02 12:35

Frank Deo

15-Jul-02 12:35

Christian Graus wrote:
Why are you using a BOOL instead of a bool ?

This may sound stupid...but, um...what the difference? Blush | :O

Christian Graus wrote:
Personally I'd also include a timeout in code like the above. What if m_Comm.GetInBufferCount() remains 0, or sInput.Find("connect") continues to be -1 ?

Its in my TODO list. Wink | ;)

Seriously, I've got 2 of these while loops. The only way I've even remotely been able to get them to exit properly is to include a 'break' after the if returns true.

Thanks Christian,

Frank

PS, whats the weather going to be like tomorrow? Poke tongue | ;-P

Christian Graus15-Jul-02 12:53

15-Jul-02 12:53

Frank Deo wrote:
This may sound stupid...but, um...what the difference?

Fair enough. A BOOL is a typedef'd int, created for C programmers. C++ has an intrinsic bool type. It is more reliable, because it is only able to be set to true or false. An int can have any value, so checking for TRUE or FALSE may in fact not catch the value something is set to.

Frank Deo wrote:
The only way I've even remotely been able to get them to exit properly is to include a 'break' after the if returns true.

Have you tried setting a break point to see if any of the conditions you're checking for ever come about ?

Frank Deo wrote:
PS, whats the weather going to be like tomorrow?

*sigh* rain, rain, rain.....

Christian

come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Frank Deo15-Jul-02 13:00

Frank Deo

15-Jul-02 13:00

Christian Graus wrote:
A BOOL is a typedef'd int, created for C programmers. C++ has an intrinsic bool type. It is more reliable, because it is only able to be set to true or false. An int can have any value, so checking for TRUE or FALSE may in fact not catch the value something is set to.

Cool, thanks for the insight. Smile | :)

Christian Graus wrote:
Have you tried setting a break point to see if any of the conditions you're checking for ever come about ?

Yea. Everywhere. When the app locks, and I break it its always on the while statement (the top of it). Dunno why.

Thanks again Christian,
Frank

Getting RuntimeClass of a CObject Derived Class

Nish Nishant15-Jul-02 14:56

Nish Nishant

15-Jul-02 14:56

bConnected never becomes TRUE I'd guess.
Perhaps this if nevere succeeds :-
if (sInput.Find("connect") != -1)

Nish

Author of the romantic comedy

Summer Love and Some more Cricket [New Win]

Review by Shog⁹
Click here for review[NW]

MightyThor15-Jul-02 12:16

MightyThor

15-Jul-02 12:16

Hi,

i have 3 objects derived from CObject.
These objects are the data source for my tree control. I want to find out which object is selected so i tried to use RUNTIME_CLASS macro.

CObject *selectedItem = ( CObject * ) m_treeMain.GetItemData( m_treeMain.GetSelectedItem() );

if( selectedItem )
{
if( selectedItem->IsKindOf( RUNTIME_CLASS( CBand ) ) )
{
AfxMessageBox( "so far so good" );
}
}

This code causes two errors :

1) error C2039: 'classCBand' : is not a member of 'CBand'
2) error C2065: 'classCBand' : undeclared identifier

What is this classCBand anyway?
I included Band.h into this function's file. And when i replace CBand with another class name such as CObject or CTreeCtrl, it works. So what's wrong with my class? What should i do to retrieve the runtime class ?

Thanks in advance.

Re: Getting RuntimeClass of a CObject Derived Class

Christian Graus15-Jul-02 12:34

Re: Getting RuntimeClass of a CObject Derived Class

15-Jul-02 12:34

There is a macro you need to include in your class for this stuff to be declared. I was forced to use this crap by a former employer, it is at best a hack. You should instead use dynamic_cast, which works for anything, not just CObject derived stuff.

CBand *selectedItem = dynamic_cast<CBand*>( m_treeMain.GetItemData( m_treeMain.GetSelectedItem() ));

if( selectedItem )
{
   AfxMessageBox( "so far so good" );
}

dynamic_cast returns NULL if the cast is invalid, otherwise the object requested. It also tells you at compile time if the cast you are attempting is unreasonable.

Christian

come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Roman Fadeyev15-Jul-02 19:03

Roman Fadeyev

15-Jul-02 19:03

If you use dynamic_cast, check up option "Enable Run-Time type info" in your project settings. It is switched off by default, AFAIK

Re: Getting RuntimeClass of a CObject Derived Class

Christian Graus15-Jul-02 19:13

Re: Getting RuntimeClass of a CObject Derived Class

15-Jul-02 19:13

That is true. I forgot that one, sorry. Blush | :O

Christian

come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

MightyThor15-Jul-02 23:35

MightyThor

15-Jul-02 23:35

Thank you both for your help. It's working fine now.
But i had to do a minor change in your code sample.

CBand *selectedItem = dynamic_cast<cband*>( (CObject*)
m_treeMain.GetItemData(
m_treeMain.GetSelectedItem() ));

if( selectedItem )
{
AfxMessageBox( selectedItem->GetBandName() );
}

I don't know why but it didn't directly cast from DWORD to CBand and gave the following message :

error C2681: 'unsigned long' : invalid expression type for dynamic_cast

So i decided to cast it to CObject* first. Frankly, i didn't quite understand why this change made it work, but it did, so i just moved on

Anyway, thanks again. Cool | :cool:

excel automation, hprocess is not closing

pnpfriend15-Jul-02 12:10

pnpfriend

15-Jul-02 12:10

hi all,
I found an article about I have an excel automation dos based application . I take an article,
Automate excel from c++ without using mfc or #import (Q216686) as an example.

then based on another article Automate excel and then know the use closed it(Q192348)
I changed my code again. actually, i added,

<br />
// wait until the user close the application<br />
<br />
    HWND hWnd;<br />
    char buf[1024];<br />
    hWnd = ::FindWindow("XLMain",NULL);<br />
    if(NULL==hWnd)<br />
    {<br />
      long lErr = GetLastError();<br />
      sprintf(buf, "FindWindow Error code = %d",lErr);<br />
      AfxMessageBox(buf);<br />
    }<br />
    <br />
    DWORD pid;<br />
    DWORD dThread;<br />
    DWORD dwReason;<br />
    dThread = ::GetWindowThreadProcessId(hWnd,&pid);<br />
    HANDLE hProcess;<br />
    hProcess = ::OpenProcess(SYNCHRONIZE|PROCESS_ALL_ACCESS,TRUE,pid);<br />
<br />
    dwReason = ::WaitForSingleObject(hProcess,INFINITE);<br />
    ::CloseHandle(hProcess);<br />

everything is fine except
dwReason = ::WaitForSingleObject(hProcess,INFINITE);
is waiting forever because in windows task manager's processes tab, you will find EXCEL.EXE eventhough you have closed ms excel application.

if you command the line
dwReason = ::WaitForSingleObject(hProcess,INFINITE);
you will not find EXCEL.EXE in windows task manager's processes tab.
why is that?

please......

pnpfriend16-Jul-02 2:44

pnpfriend

16-Jul-02 2:44

can someone help me please Cry | :((

Re: excel automation, hprocess is not closing

Richard Ellis16-Jul-02 14:05

Richard Ellis

16-Jul-02 14:05

G'Day Win,

I use the same code successfully. What I discovered was that as I developed the application I would run it and terminate it prematurely with Excel open. This of course did not close down excel properly. So that when I started the application again I had 2 versions of excel running etc. Thus when I had a 'real' excel application running and I tested my program and shut excel down this code failed because I had closed down a different excel to the one being watched. I think this is what may be happening in your case. So terminate all excel processes with task manager, run excel and then your application and see if it works then.

Hope that is of some help,

Richard.

Re: excel automation, hprocess is not closing

pnpfriend17-Jul-02 3:39

pnpfriend

17-Jul-02 3:39

thank you Richard.
that's is a really helpful. Thanks

derive a class from my tree control

Steve L.15-Jul-02 11:39

Steve L.

15-Jul-02 11:39

I need to handle the WM_MOUSEMOVE message for my tree control. I've been told that I have to derive a class from my tree control and handle mousemove int there but I can't figure out how to derive the class from my tree control.

-Raffi

Joaquín M López Muñoz15-Jul-02 11:43

Joaquín M López Muñoz

15-Jul-02 11:43

It's simple. Launch the MFC wizard (CTRL+W) and create a new class selecting CTreeCtrl as the base class (call it CMyTreeCtrl, for instance.) Handle WM_MOUSEMOVE in the new class. Now, where you defined a variable of type CTreeCtrl, replace CTreeCtrl with CMyTreeCtrl (you'll need to include "mytreectrl.h", also.) That's it.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Steve L.15-Jul-02 11:50

Steve L.

15-Jul-02 11:50

I previously have all my tree control code in my view class. Do I have to move all my tree control code to this new class or will it work with just leaving it as is and doing what you said above?

-Raffi

Joaquín M López Muñoz15-Jul-02 12:01

Joaquín M López Muñoz

15-Jul-02 12:01

It'll work by only replacing CTreeCtrl with the new class, you can leave all the other stuff where it was

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo