C / C++ / MFC

9-Dec-02 4:39

I don't understand what is happening here.
Anyone able to elucidate?
I have a full screen window. (a vanilla
CWnd derivative) This works fine. It covers
the task bar and all ok. The problem comes
when it creates a full screen modal dialog.
That dialog assumes full screen in OnInitDialog
(via SetWindowPos).

The problem is that where the task bar
would have been shown, had this not been a full
screen window, the parent window shows through
instead!

I have worked around the problem, by hiding the
parent window. But I'd really like to know what
is going on here.

..especially why the work around of hiding the
parent window should fix it!

#realJSOP9-Dec-02 5:14

#realJSOP

9-Dec-02 5:14

Without playing around with this, I suspect that you'd have to override the OnSize() method for the dialog's CWnd. The original is probably taking into account the size of the taskbar. That's the first place I would look.

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

Scott H. Settlemier9-Dec-02 5:24

9-Dec-02 5:24

I check the size of the window in OnPaint. The dialog
is sized as it should be-- full screen. It paints that
region where the parent shows through as well. It's as
if the parent window were made up of two parts, with
the region where the taskbar would have been, behaving
as if it were topmost. Most strange-- enough that I
suspect some unknown OS behavior or a bug.
(I'm running on XP here.)

mediamaster409-Dec-02 6:15

mediamaster40

9-Dec-02 6:15

I see this same problem. I am creating a full screen borderless window with flags TOPMOST for my screen saver window. On Windows 98 when I call the password verification dialog, the dialog only sometimes draws above the screen saver window. MS screen savers work fine, but they must be doing some magic thing to get theirs to work? I have tried several things, none of which seem to work including:

1) Setting my full screen window to the bottom of the Z order.
2) Creating the dialog in another thread.
3) Disabling the full screen window painting when the dialog is active, thinking it might be painting over the dialog.

But none of these things seem to work, any ideas here, I imagine it might be the same problem as Scott H. Settlemier is having.

Stop playing AC2 and please help us oh great Win32 gurus...

Joan M9-Dec-02 20:23

Joan M

9-Dec-02 20:23

I've had your same problem last week...

It's due to the system workarea.

You must resize the workarea at the beggining of your app. and resize again at the end of your app.

here's the code:

<br />
CRect rectWorkArea;<br />
<br />
rectWorkArea.left   = 0;<br />
rectWorkArea.top    = 0;<br />
rectWorkArea.right  = ::GetSystemMetrics(SM_CXSCREEN);<br />
rectWorkArea.bottom = ::GetSystemMetrics(SM_CYSCREEN);<br />
<br />
SystemParametersInfo(SPI_SETWORKAREA,0,&rectWorkArea,SPIF_SENDCHANGE);<br />

then you can resize your dialogs and windows as always...

NOTE:
I had to resize the windows using this:

<br />
this->SetWindowPos(&wndTopMost,0,0,::GetSystemMetrics(SM_CXSCREEN),::GetSystemMetrics(SM_CYSCREEN),SWP_SHOWWINDOW);<br />

TopMostFlag is an option...

this had to be done in order to avoid flickering when I used the common way of resizing...

Hope this helps...

Scott H. Settlemier10-Dec-02 4:01

10-Dec-02 4:01

NEW INFO:

I checked the clip box in OnPaint. It was
0,30 to 1024,768!!! But the area showing
through was at the bottom. It looked like
the window had been somehow moved from
where I set it with SetWindowPos. So I
checked the window rect and the window
was now 0,-30 to 1024,738!! I had set the
coordinates to 0,0 to 1024,768.

The SetWindowPos call did not use SWP_SHOWWINDOW
since I wanted to wait until all of my initialization
had completed in OnInitDialog. When I added
SWP_SHOWWINDOW, the problem cleared up.

So it looks to me that there may indeed be a Windows
bug here. Something shifted my window up, just
the amount that is the size of the taskbar.
If I place the taskbar to the side, the window will
get shifted to the side.

Very perplexing...
Any clues as to what is happening?

mediamaster4010-Dec-02 4:23

mediamaster40

10-Dec-02 4:23

That is most likely the task bar shifting the window about. The taskbar must always be visable and will move windows accordingly if they get in the way. Try setting the taskbar to 'AutoHide' then see if you have these same issues, I bet you won't. But I wonder if the taskbar should even be moving your window since you are manually forcing it be fullscreen, I would think the taskbar should only move windows that are maximized, not that set the window position and size directly.

Scott H. Settlemier10-Dec-02 6:41

10-Dec-02 6:41

Right, I don't think anyone should be moving the window
after I have set its position. It is not a maximized window,
merely a full screen window. That the problem does not occur
if I pass SWP_SHOWWINDOW in the call to SetWindowPos, makes
me suspect that this is not just unexpected behavior, but
a bug. (after all, it shouldn't matter a lick to the OS
whether the window has been painted already or not!)

fopen and CStringArray

Anonymous9-Dec-02 3:09

Anonymous

9-Dec-02 3:09

I am opening a text file with fopen. I can read in text strings and assign them to a CString. I am trying to set the CString in a CStringArray for later use but the computer doesn't like it.

CString s;
FILE *pSkinfile = fopen ((LPCTSTR) lpFileName2, "rt");
if (!pSkinfile)
{
return false;
}

do
{
fgets (szLine, 256, pSkinfile);
for(zero = 0; zero < numSurf; zero++)
{
match = strncmp (szLine, stringArraySurfaces.GetAt(ij), n_lengthArray[ij]);
if(match == 0)
{
sscanf (szLine, "%s", S1);
->This line screws it up stringArrayPath.SetAt(ij,S1);
}
ij++;
}
ij = 0;

}while(feof(pSkinfile) == 0);

fclose (pSkinfile);

Is this because I'm reading in a stream and can't output to a variable?

Gary Kirkham9-Dec-02 3:25

Gary Kirkham

9-Dec-02 3:25

You didn't say what the error was, so I may be way off base. Did you set the size of stringArrayPath using SetSize. The SetAt function will not grow the array, so you need to be sure you are writting to a valid location. You should either set the size of the array or use the SetAtGrow function or the Add function.

Gary Kirkham

A working Program is one that has only unobserved bugs

Nitron9-Dec-02 4:10

Nitron

9-Dec-02 4:10

Or better yet, use

int nStrings = -1;
std::vector<CString*> pszStrings;

then for each new string:

{
  nStrings++;
  pszStrings->push_back(new CString);
  pszStrings[nStrings]->Format("%s",YourStringToSet);
}

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

Christian Graus9-Dec-02 8:59

Christian Graus

9-Dec-02 8:59

AS has been said, you should use vector. I'd also use iostreams, then if you use std::string it's as easy as using getline to read in the strings, none of this stuffing around with C.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002