C / C++ / MFC

Re: How to open new windows at the top of z-order, when process is not current process ?

9-Jun-04 18:01

Diddy wrote:
AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),TRUE);

SetForegroundWindow();
SetFocus();

AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),FALSE);

This is exactly what I want, thanks.

Two questions though:

Shouldn't the ThreadProcessId be stored when GetWindowThreadProcessId() is first called ? Otherwise, when you call it the second time, you are getting the ThreadProcessId of your apps window and not the original window, since it is no longer the Foreground Window.

Also, will it not make the other app unstable, because by stealing the threads input for a short period, you are also stealing its' messages. This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app. Bit of a convoluted description, I know Blush | :O

)

Anyway, will it make the other app (or my app) unstable ?

Thanks again for your help.

Diddy9-Jun-04 23:44

Diddy

9-Jun-04 23:44

1) Yes

) Thats called me trying to attack the situation with copy and paste Blush | :O

) Well spotted.

2) No. It's not stealing its input - its stealing - or rather sharing - its input states. Each thread has a number of states associated with all the windows it has created - such as the one that has the focus, and the curent cursor for each etc. When you call SetFocus, it says is the focus state set for our thread for at least one window we have created - if thats a no, it does nothing - if its a yes, it sets the focus to the window provided. AttachThreadInput simply combins the states for both threads, so thread A and thread B are now working with the same state - since you are attaching to the current forground window, your focus state is now set and you can change the focus to one of your own windows.

In other words:

defenestration wrote:
This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app

Isn't true - its nothing to do with the messages - just to do with certian states of the thread (specifically focus, active, capture windows, key state, queue status, and so on).

It's the recomended way by MSDN anyway - and I have used it for ages with no stabality problems. One thing to be aware of - never put a break point between attaching and detacting. If you are debuging - you will be attaching to MSDEVS thread, and because your app is being debugged, you will be bascially freeze the debugger.

Hope it helps

Re: How to open new windows at the top of z-order, when process is not current process ?

Defenestration10-Jun-04 11:20

Integer & floating point divide by zero...

10-Jun-04 11:20

Diddy wrote:
Hope it helps

It certainly has. Thanks for the explanation Diddy!

herbert_chow8-Jun-04 12:12

herbert_chow

8-Jun-04 12:12

Hi,

I'm in the process of making my program more robust. I've had a couple integer divide by zero exceptions from my program so I am now going through all divisions within my code and maknig sure they aren't 0.

However, just wondering if there is such thing as floating point divide by zero? I can't seem to find such an exception and coudlnt' generate it myself for testing. Do FLOATs work differently than integers?

Thanks in advance!

John R. Shaw8-Jun-04 15:52

8-Jun-04 15:52

I ran a test and to my supprise, no exception was generated! Why? I am still looking for the answer.

Look in MSDN library under the following:
"Floating-Point Exception Modes"
and
"_controlfp"

I hope that is some help!

Here is a clip from a math parser I wrote (in C) back in 1994 (the code still works):

/* --------------------------------------------------------------------- */
/*
**  Note: The purpose of the arrays is to prevent
**      multiple copys of error strings being used.
*/
int matherr( struct exception *except )
{
    char t = *(_User.def.name);
    int endx=-1, sndx=-1, n = _User.def.nargs;
    char *str[2] = { "is","caused" };
    char *errors[6] =
    {
        "outside the domain",            /* 0 */
        "an illegal value",              /* 1 */
        "overflow",                      /* 2 */
        "underflow",                     /* 3 */
        "partial loss of significance",  /* 4 */
        "total loss of significance",    /* 5 */
    };
    switch( except->type )
    {
        case DOMAIN:    endx = 0 ; sndx = 0 ; break ;
        case SING:      endx = 1 ; sndx = 0 ; break ;
        case OVERFLOW:  endx = 2 ; sndx = 1 ; break ;
        case UNDERFLOW: endx = 3 ; sndx = 1 ; break ;
        case PLOSS:     endx = 4 ; sndx = 1 ; break ;
        case TLOSS:     endx = 5 ; sndx = 1 ; break ;
    }
    if( t && endx>-1 && sndx>-1)
    {
        /* if there is only one argument it has to have caused the error */
        /***** REMOVE THIS FOR "GRAPHIT" ERROR PRINTING ******************
        if( n == 1 )
            _Error( "math","'%s': %G %s %s",
                    _User.def.name,except->arg1,str[sndx],errors[endx] );
        else
        ******************************************************************/
            _Error( "math","'%s': argument %s %s",
                    _User.def.name,str[sndx],errors[endx] );
    }
    else _Error( "math",errors[endx] );
    return 1;
}
/* --------------------------------------------------------------------- */

#include <float.h>
#include <signal.h>
static void fphandler( int sig, int num );

static char *_FpeErrors[10] =
{
    "invalid number",                   /* 0 */
    "denormal",                         /* 1 */
    "divide by zero",                   /* 2 */
    "overflow",                         /* 3 */
    "underflow",                        /* 4 */
    "inexact",                          /* 5 */
    "unemulated",                       /* 6 */
    "square root of negative number",   /* 7 */
    "stack underflow",                  /* 8 */
    "unknown",                          /* 9 */
};

void p_setfperror(void)
{
    /* Set up floating-point error handler. */
    if( signal( SIGFPE, fphandler ) == SIG_ERR )
        _Error( "p_setfperror","could not set floating point error handler" );
    else _FpeSet = 1;
}

/* Handles SIGFPE (floating-point error) interrupt. */
static void fphandler( int sig, int fperr )
{
    int ndx;
    /* Initialize floating-point package. */
    _fpreset();

    /* This function my be causing a stack underflow */
    /* Stop multiple _FpeMsg setting */
    if( _Error_Flag > -1 )
    {
        switch( fperr )
        {
            case FPE_INVALID:           ndx = 0; break;
            case FPE_DENORMAL:          ndx = 1; break;
            case FPE_ZERODIVIDE:        ndx = 2; break;
            case FPE_OVERFLOW:          ndx = 3; break;
            case FPE_UNDERFLOW:         ndx = 4; break;
            case FPE_INEXACT:           ndx = 5; break;
            case FPE_UNEMULATED:        ndx = 6; break;
            case FPE_SQRTNEG:           ndx = 7; break;
            case FPE_STACKUNDERFLOW:    ndx = 8; break;
            default:                    ndx = 9;
        }
        _FpeMsg = _FpeErrors[ndx];
    }
    _Error_Flag = -1;
}

Good Luck!

INTP

Anonymous8-Jun-04 18:06

Anonymous

8-Jun-04 18:06

Thanks for the resources. Would you happen to know what the Alpha machines are? I guess we're concerned with x86 right?

I still can't generate a floating point divide by zero. Perhaps the compiler is doing something so that it gets trimmed away. But I just hope it doesn't happen in my program Smile | :)

Has anyone actually seen a floating point exception before? One related to arithematic error? I don't think I have.

Thanks!

John R. Shaw8-Jun-04 19:04

8-Jun-04 19:04

Ryan is right about the infinity thing, but the code sample I gave you was from a math parser that did catch divide-by-zero (all calculations where done using double values).

May be you sould also look up: "ID: Q72726"

The best solution of course is to always test the denominator to make sure it is not zero before using it.

INTP

Ryan Binns8-Jun-04 18:26

Ryan Binns

8-Jun-04 18:26

herbert_chow wrote:
However, just wondering if there is such thing as floating point divide by zero? I can't seem to find such an exception and coudlnt' generate it myself for testing. Do FLOATs work differently than integers?

A floating-point divide-by-zero doesn't generate an exception - even at the FPU level. FPU's know that anything divided by 0 is infinite, so they actually return a result of infinity (which is a valid number in the IEEE floating point formats, BTW). They don't flag an error condition, so the only way you can check is to determine if the result is infinity.

However, a much better way is to make sure it never happens in the first place... Wink | ;)

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

herbert_chow8-Jun-04 20:34

herbert_chow

8-Jun-04 20:34

Just to point out.. that anonymous user was me, I forgot to log in.

Thanks for the great tips everyone! The SIGFPE handler interrupt is something I will need to look into as although I've worked with SIGFPE at the C level for an operating systems course. Im not quite sure how to incorporate it into Visual C++ though.

But I guess I got the main point which is to always check that I'm not dividing by zero.

Well... time to start checking EVERY division in my code.

Child window resizing..

Bob Stanneveld8-Jun-04 12:10

8-Jun-04 12:10

Hello,

I'm working on a dialog based application. I need some sort of Panel (like in Delphi) in the main window.
I figured that a panel is nothing more than a modeless child window without any borders.

I derived a class from CDialog and I put some controls on it (edit boxes and such). It all works fine, the window hides and appears when I want it to, the controls work fine (button's get pushed, data moves from and to edit controls), BUT when I try to move the child window, it stays put.
I move the child window like this:

<br />
if(((CMyDialog*) m_pdlg)->SetWindowPos(this, 200, 50, 0, 0, SWP_NOSIZE | SWP_SHOWWINDOW))<br />
		AfxMessageBox("test");<br />

The messagebox appears, so the window should be moved, but it doesn't... Confused | :confused:

I'm all out of clues and fried by my monitor and manuals...

Does anybody know a solution?

Thanks in advance.

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

valikac8-Jun-04 12:57

valikac

8-Jun-04 12:57

Interesting.

Are you passing in a coordinate that is different than the current one?

Kuphryn

Bob Stanneveld9-Jun-04 5:01

9-Jun-04 5:01

Hello,

I didn't pass the same coordinates, but I solved the problem now Big Grin | :-D

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Vadim Tabakman8-Jun-04 13:57

Vadim Tabakman

8-Jun-04 13:57

There's always MoveWindow, if you are having problems and make sure that the coordinates are in the parent window coordinates.

Bob Stanneveld9-Jun-04 5:03

9-Jun-04 5:03

Hello,

I solved the problem now Big Grin | :-D

. I don't know why it didn't work before, but it's solved now..

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Solution!

Bob Stanneveld9-Jun-04 5:01

Why do VC++6 Service Packs cause code size to vary ?

9-Jun-04 5:01

Hello,

I solved the problem. When I don't typecast the m_pdlg to CMyDialog* everything works fine...

I don't know why I can't typecast m_pdlg to CMyDialog*, but it works fine now Smile | :)

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Defenestration8-Jun-04 11:49

Re: Why do VC++6 Service Packs cause code size to vary ?

8-Jun-04 11:49

When building CodeProject examples (and other source code), I have noticed that the file size of the Release executables that I create, are larger than the Release executables created by the authors of the examples. I couldn't figure out why, but after re-installing XP and VC++6, I forgot to install SP5, and noticed that the Release executables produced were a different size to the ones created when SP 5 had been installed. Sometimes they were larger, sometimes smaller.

For example, if I install VC++6, without the service pack, I end up with a Release executable size of 528KB. With Service Pack 5 installed, this reduces to 444KB.

I've noticed this peculiarity before when compiling the QCD (Great media
player) Monkey's Audio input plugin - My plugin is 202KB, compared to the
official plugin which is 153KB. Everybody else I've spoken to can compile it
and produce a plugin of 153KB. It seems I'm the only one with the problem Blush | :O

(

Also, when compiling a viewer plugin for the Directory Opus file manager, the dll produced is 32KB without SP5, and 44KB with SP5.

What's going on ?

John R. Shaw8-Jun-04 16:09

Re: Why do VC++6 Service Packs cause code size to vary ?

8-Jun-04 16:09

Hmmm! It is a service pack! This implies that some bugs where probably fixed and or some of the code was changed to be more efficient. A bug fix might increase the code size generated by the compliler, why an improvement in efficiency might result in a smaller or larger code size.

In either case the amount of code generated has changed, and is hopefully better than is was without the service pack.

INTP

Defenestration8-Jun-04 16:53

Re: Why do VC++6 Service Packs cause code size to vary ?

8-Jun-04 16:53

Thanks for the reply.

I don't understand why other people can compile the QCD plugin with VC++6 SP5 and produce a dll of size 153KB, and mine is 202KB, using exactly the same settings.

The same is true with the ToDoList project on CodeProject, where the official Release executable is 340KB, but mine is 444KB, again using the supplied project settings.

Any ideas ?

John R. Shaw8-Jun-04 19:24