Announcement

**Borje Hagsten** · 26 Feb 2001, 06:51 PM

Have you tried adding %WS_CLIPCHILDREN to the tab dialogs? Or to
the grid control itself? I think the tab dialogs always should be
children of the main dialog, to get expected results.

Maybe you can experiment with %WS_CLIPSIBLINGS in different dialogs
and controls too, to see if that can help.

------------------

**Lance Edmonds** · 26 Feb 2001, 10:30 PM

Correct. The (modeless) tab page dialogs must be children of the parent dialog, not the tab control.

The problem almost certainly sounds like a refreshing or clip region issue. It could be that you also have a problem with your message pump. If your parent dialog is a MODAL dialog, then the message pump is automatically provided by that dialog's pump, however, if all the dialogs are modeless, you need to explicitly engage a message pump that must continue to run until all MODELESS dialogs have been released.

You could also try using the %WM_CLIPSIBLINGS style with the grid control:

WS_CLIPSIBLINGS
For a child window, exclude the areas occupied by fellow children of the window's parent when drawing within the window (to avoid drawing on any sibling windows).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Bern Ertl** · 27 Feb 2001, 06:41 AM

Well....

I tried the following scenarios without success (with tabbed dialogs
children to hDlg) :

Added %WS_CLIPCHILDREN (one at a time) to

Code:

hDlg - Combobox cells still leave gray box when a selection is made.
       When another window is dragged over my sample, the hTabDlg# 
       window is 'erased'.

hTab - No visible effect

hTabDlg#'s - No visible effect

hGrid - No visible effect

then I tried adding %WS_CLIPSIBLINGS (without any %WS_CLIPCHILDREN) to:

Code:

hDlg - No visible effect

hTab - No visible effect

hTabDlg#'s - All controls on child dialogs disappeared - nothing displayed

hGrid - The grid (only) disappears and is not displayed.

The wierd thing about the combobox cells is that they DO refresh the
background if NO selection is made. They problem only manifests if
a selection is made.

I've sent a sample to the grid vendor and their tech support said that
my sample worked on their Win2000 machine. I'm running Win98, so I guess
it has something to do with Windows?

Lance, I broke out the pertinent code into a small sample when testing
for the source of the problem. My sample uses a MODAL parent dialog.
My original code uses a MODELESS dialog with a DO | DIALOG DOEVENTS | LOOP
message pump. The problem is manifest under both programs.

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited February 27, 2001).]

**Borje Hagsten** · 27 Feb 2001, 07:21 AM

Sounds like a problem within the Grid control. Maybe you can refresh
it via InvalidateRect and UpdateWindow, when this problem occurs,
that is, when a selection has been made?

------------------

**Bern Ertl** · 27 Feb 2001, 08:40 AM

That's what I thought. Thus my original question was regarding the
use of the tab key if I changed the relationship of the child dialogs.

I tried trapping the closing of the combobox cells and adding:

InvalidateRect hGrid, BYVAL 0, 0

and the window gets refreshed, but there is a noticable flicker
because the entire window gets refreshed. Oh well, I hope the grid
folks can solve the problem....

BTW, there is no problem if I add a standard combobox control directly
onto the child dialogs. It is only within the combobox cells of the grid.

------------------
Bernard Ertl

**Borje Hagsten** · 27 Feb 2001, 08:50 AM

If you can get a handle of the combo, you can use CB_GETDROPPEDCONTROLRECT
to get the area that needs to be updated in a RECT var and use
CALL InvalidateRect(hWnd, rc, -1) instead.

------------------

**jcfuller** · 27 Feb 2001, 09:40 AM

Bernard,
The InvalidateRect is the only way I found to correct the problem. I don't
have any flicker but I'm not sure how/if I fixed it. (might just be a faster CPU now).
I have code in my OnLeaveCell Proc that checks for a combo and then Posts a WM_USER+xxx msg
to my Dialog which inturn Invalidates itself.
I think I reported this to Farpoint with ver 2.5.??

James

------------------

**Bern Ertl** · 27 Feb 2001, 10:29 AM

Thanks Borje, I'm not sure I can get the handle to the combobox in the cell,
but I'll investigate.

James,
I trapped the %SSM_COMBOCLOSEUP message for the Invalidate call.

If you could post/email a small sample showing your solution (flicker free?)
I'd appreciate it. I'd be happy to post/email a small app demonstrating my
problem if you like.

I'm going to continue pushing Farpoint for a bug fix.

------------------
Bernard Ertl

**Borje Hagsten** · 27 Feb 2001, 11:17 AM

It should have a handle and if it's part of the Grid control, GetNextWindow
or GetTopWindow should be able to find it. Otherwise, just simulate some
area around GetCursorPos to see if it will work at all.

------------------

**Bern Ertl** · 27 Feb 2001, 12:38 PM

Well...

I got the following reply from Farpoint tech. support regarding
the problem I've been experiencing with their Spread/grid control:

I used Spy to watch messages coming into the Spread, and it never does
get a WM_PAINT message after a selection in the combobox is made. This
is because the area is never being invalidated by the parent dialog. I
think this is because you have the dialog as a child of another dialog.
This is bad practice, at least in Visual C++ programming. It may be in
all Windows programming. This is why, when you call the InvalidateRect
API on the Spread, it paints correctly. You may want to look in the
newsgroups about problems with messaging when you have a dialog as a
child of a dialog.

So how about it, is there a problem with messaging in child DDT DIALOGS?
Or perhaps I'm missing a [extended?] style from my declarations?

Help!

Here's my sample program which demonstrates the problem (you won't
be able to run it without Farpoint's Spread 3.0 DLL). Maybe you can
see something obviously wrong with the DIALOG declarations?

Code:

'// PowerBASIC's PBDLL 6.0 sample code


   #COMPILE EXE
   #REGISTER NONE
   #DIM ALL


'// The following are directions to the COMMCTRL include file
'// not to include DECLARES for unnecessary controls.
    %NOANIMATE       = 1 : %NOBUTTON        = 1 : %NOCOMBO         = 1
    %NODRAGLIST      = 1 : %NOHEADER        = 1 : %NOHOTKEY        = 1
    %NOIMAGELIST     = 1 : %NOPIADDRESS     = 1 : %NOLIST          = 1
    %NOLISTVIEW      = 1 : %NOMONTHCAL      = 1 : %NONATIVEFONTCTL = 1
    %NOPAGESCROLLER  = 1 : %NOPROGRESS      = 1 : %NOREBAR         = 1
    %NOSTATUSBAR     = 1 : %NOTRACKBAR      = 1 : %NOTREEVIEW      = 1
    %NOUPDOWN        = 1 : %NODATETIMEPICK  = 1 : %NOTOOLBAR       = 1
'    %NOTABCONTROL    = 1
'    %NOTOOLTIPS      = 1
#INCLUDE "COMMCTRL.INC"


'// Spread C language header file translated to PowerBASIC
#INCLUDE "SPREAD30.INC"


   %ID_TAB = 1001


'// This is the child window with the Spread control
   CALLBACK FUNCTION TabProc1


      LOCAL x&, y&, hSpread&, Result&, Temp$
      LOCAL szHeader AS ASCIIZ * 100
      LOCAL szTemp AS ASCIIZ * 100
      LOCAL ct AS SS_CELLTYPE
      LOCAL cellSize AS DOUBLE
      LOCAL cb AS SUPERBTNCOLOR


      SELECT CASE CBMSG
         CASE %WM_INITDIALOG
            CONTROL ADD FRAME, CBHNDL, 100, " Make a selection from a combobox, then try again without making a selection.", 0, 0, 255, 140
            CONTROL ADD "fpSpread30", CBHNDL, 101, "", 5, 15, 245, 120, _
                       %SSS_NOSELECTBLOCK OR %WS_CHILD OR %WS_VISIBLE OR %WS_BORDER OR %WS_TABSTOP, %WS_EX_CLIENTEDGE ,


'// The following code is cut & paste from my
'// main application.
   hSpread& = GetDlgItem( CBHNDL, 101)


   Temp$ = "T/A" + $TAB + "Pre-T/A" + $TAB + "Post-T/A" + CHR$(0)
'// Original call to ComboBoxEx.  Tried using just ComboBox below,
'// but it does not change the dropdown box behavior.
'   Result& = SSSetTypeComboBoxEx( hSpread&, ct, %SSS_ALIGN_VCENTER OR %SSS_ALIGN_LEFT, _
'                  BYVAL STRPTR(Temp$), 3, 0, -1, BYVAL 0)
   Result& = SSSetTypeComboBox( hSpread&, ct, %SSS_ALIGN_VCENTER OR %SSS_ALIGN_LEFT, _
                  BYVAL STRPTR(Temp$))
   Result& = SSSetCellType( hSpread&, 5, %SS_ALLROWS, ct)


   Temp$ = "1-8 Days" + $TAB + "1-8 Nights" + $TAB + "2-8's" + $TAB + _
           "1-9 Days" + $TAB + "1-9 Nights" + $TAB + "2-9's" + $TAB + _
           "1-10 Days" + $TAB + "1-10 Nights" + $TAB + "2-10's" + $TAB + _
           "1-11 Days" + $TAB + "1-11 Nights" + $TAB + "2-11's" + $TAB + _
           "1-12 Days" + $TAB + "1-12 Nights" + $TAB + "2-12's" + $TAB + _
           "3-8 S.1" + $TAB + "3-8 S.2" + $TAB + "3-8 S.3" + $TAB + _
           "3-8 S.1&2" + $TAB + "3-8 S.2&3" + $TAB + "3-8 S.1&3" + $TAB + "3-8's" + CHR$(0)
   Result& = SSSetTypeComboBoxEx( hSpread&, ct, %SSS_ALIGN_VCENTER OR %SSS_ALIGN_LEFT, _
                  BYVAL STRPTR(Temp$), 15, 0, -1, BYVAL 0)
   Result& = SSSetCellType( hSpread&, 6, %SS_ALLROWS, ct)


'// End of cut & paste from original code.


         CASE %WM_SIZE
            DIALOG GET SIZE CBHNDL TO x&, y&
            CONTROL SET SIZE CBHNDL, 100, x&, y&
            CONTROL SET SIZE CBHNDL, 101, x& - 10, y& - 20
'// The following will solve the problem, but makes the
'// screen "flicker"
'         CASE %SSM_COMBOCLOSEUP
'            InvalidateRect hSpread&, BYVAL 0, 0
      END SELECT
   END FUNCTION


'// Generic tab
   CALLBACK FUNCTION TabProc2
      LOCAL x&, y&
      SELECT CASE CBMSG
         CASE %WM_INITDIALOG
            CONTROL ADD FRAME, CBHNDL, 100, " Tab 2 ", 0, 0, 255, 140
            CONTROL ADD TEXTBOX, CBHNDL, 101, "Textbox #2", 10, 20, 235, 80, _
               %ES_MULTILINE OR %ES_WANTRETURN OR %WS_TABSTOP, %WS_EX_CLIENTEDGE
         CASE %WM_SIZE
            DIALOG GET SIZE CBHNDL TO x&, y&
            CONTROL SET SIZE CBHNDL, 100, x&, y&
            CONTROL SET SIZE CBHNDL, 101, x& - 20, y& - 60
         END SELECT
   END FUNCTION


'// Generic tab
   CALLBACK FUNCTION TabProc3
      LOCAL x&, y&
      SELECT CASE CBMSG
         CASE %WM_INITDIALOG
            CONTROL ADD FRAME, CBHNDL, 100, " Tab 3 ", 0, 0, 255, 140
            CONTROL ADD TEXTBOX, CBHNDL, 101, "Textbox #3", 10, 20, 235, 80, _
               %ES_MULTILINE OR %ES_WANTRETURN OR %WS_TABSTOP, %WS_EX_CLIENTEDGE
         CASE %WM_SIZE
            DIALOG GET SIZE CBHNDL TO x&, y&
            CONTROL SET SIZE CBHNDL, 100, x&, y&
            CONTROL SET SIZE CBHNDL, 101, x& - 20, y& - 60
      END SELECT
   END FUNCTION


'// Parent window callback
   CALLBACK FUNCTION MainDlgProc
      STATIC LastIdx AS LONG, hWndTab() AS LONG
      LOCAL tie AS TC_ITEM, i AS LONG, Caption AS STRING
      LOCAL x&, y&
      %nTabCh = 3
      SELECT CASE CBMSG
         CASE %WM_INITDIALOG
            CONTROL ADD "SysTabControl32", CBHNDL, %ID_TAB, "", 10, 10, 280, 180, %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP ', %WS_EX_CONTROLPARENT
            REDIM hWndTab(1 TO %nTabCh)
            FOR i = 1 TO %nTabCh
               DIALOG NEW CBHNDL, "", 20, 35, 255, 140, %DS_CONTROL OR %WS_CHILD TO hWndTab(i)


'// The following (in place of the above line) also solves the combobox cell problem, but causes
'// the tab key to stop working properly.
'               DIALOG NEW GetDlgItem(CBHNDL, %ID_TAB), "", 5, 15, 270, 160, %DS_CONTROL OR %WS_CHILD TO hWndTab(i)


               SELECT CASE i
                  CASE 1
                     DIALOG SHOW MODELESS hWndTab(i) CALL TabProc1: Caption = " One "
                  CASE 2
                     DIALOG SHOW MODELESS hWndTab(i) CALL TabProc2: Caption = " Two "
                  CASE 3
                     DIALOG SHOW MODELESS hWndTab(i) CALL TabProc3: Caption = " Three "
               END SELECT
               IF i = 1 THEN ShowWindow hWndTab(i), %SW_SHOW ELSE _
                  ShowWindow hWndTab(i), %SW_HIDE
               tie.mask = %TCIF_TEXT OR %TCIF_IMAGE
               tie.iImage = -1
               tie.pszText = STRPTR(Caption)
               TabCtrl_InsertItem GetDlgItem(CBHNDL, %ID_TAB), i, tie
            NEXT
            SetFocus GetDlgItem(CBHNDL, %ID_TAB)
         CASE %WM_SIZE
            DIALOG GET SIZE CBHNDL TO x&, y&
            CONTROL SET SIZE CBHNDL, %ID_TAB, x& - 20, y& - 45


            FOR i = 1 TO %nTabCh
                DIALOG SET SIZE hWndTab( i), x& - 45, y& - 85
            NEXT
         CASE %WM_NOTIFY
            LOCAL lpNmh AS NMHDR PTR
            lpNmh = CBLPARAM
            SELECT CASE @lpNmh.Code
               CASE %TCN_LAST TO %TCN_FIRST
                  SELECT CASE @lpNmh.idFrom
                     CASE %ID_TAB
                       SELECT CASE @lpNmh.Code
                          CASE %TCN_SELCHANGE
                             i = TabCtrl_GetCurSel(GetDlgItem(CBHNDL,%ID_TAB))
                             ShowWindow hWndTab(LastIdx + 1), %SW_HIDE
                             LastIdx = i: ShowWindow hWndTab(LastIdx + 1), %SW_SHOW
                       END SELECT
               END SELECT
            END SELECT
      END SELECT
   END FUNCTION


'// Winmain equivalent - this is the starting procedure
   FUNCTION PBMAIN
      LOCAL hDlg AS LONG
      InitCommonControls
      DIALOG NEW 0, "Bernard Ertl's ComboBox Problem",,, 300, 225, _
         %WS_SIZEBOX OR %WS_MINIMIZEBOX OR %WS_MAXIMIZEBOX OR %WS_CAPTION OR _
         %WS_SYSMENU, %WS_EX_CONTROLPARENT TO hDlg
      DIALOG SHOW MODAL hDlg CALL MainDlgProc
   END FUNCTION

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited February 27, 2001).]

**Eric Pearson** · 27 Feb 2001, 02:04 PM

Bern --

> So how about it, is there a problem with
> messaging in child DDT DIALOGS?

I think I can rule out DDT problems...

By a strange coincidence, I am working on a project that uses a Spread grid on a tab, on a dialog. And I just spend the day wrestling with redisplay problems. But my project does not use any DDT at all, it is 100% API-based (dialogs from resource files, actually), and I am seeing problems that are very similar to yours.

Here's another twist. Using your test app, select a combo box. Then minimize and restore the app, and the grid will disappear completely.

I have not looked at your app in detail yet, because I am too focused on mine. This problem has my full attention right now, and if I find a solution I will post it here. Maybe with both of us working on it...

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

**Bern Ertl** · 27 Feb 2001, 02:47 PM

Wierd!

You're right. The spread control dissappeared. I assume you've
already played with WS_CLIPCHILDREN & WS_CLIPSIBLINGS without
success?

Have you tried assigning your child dialogs to the tab control
instead of the parent window? It solves the combobox cell refresh
problem on my sample, but locks up the app when I try your minimize
"trick".

Have you contacted Farpoint about the problem on your end?

P.S. There was a snafu in communication when I sent Farpoint tech.
support my sample. The earlier report that the problem did not
manifest under Win2000 was incorrect. I had sent them the wrong
version of the sample. I resent the correct version and it does
indeed manifest under all Windows platforms (that have been tested
so far anyway - Win95, Win98, Win2000).

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited February 27, 2001).]

**Eric Pearson** · 27 Feb 2001, 03:09 PM

> Have you contacted Farpoint about
> the problem on your end?

No. I contacted them recently about a problem I was having, and it turned out to be a situation that is specific to dialogs. They didn't know about it... another Spread user that frequents this forum finally figured it out. Apparenly not many of Farpoint's customers use dialog-based window, so I don't expect them to be much help, at least early in the game.

I don't think this is a problem with the Spread grid, per se, I suspect this is one of those quirks that is unique to dialog-based windows. I just have to figure out which one...

-- Eric

[added later] I see now that James has already contributed to this thread. He's the person that figured out the other dialog-based problem.

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited February 27, 2001).]

**Bern Ertl** · 27 Feb 2001, 03:43 PM

OK. I'm not too proud to show my extreme ignorance.

What do you mean by "dialog based windows"? What other type of window
would you use the Spread control with?

I thought everything was a dialog/window. Every control and every dialog
is a window of some sort, right? They just have different properties,
no?

I'm assuming that the Spread control itself is a dialog window which
contains the controls which comprise the grid? Is the problem really
about messaging from a parent dialog to a child dialog (tabDlg) to a child
dialog (Spread control)?

When I click on the combobox cell in Spread control, how does Windows
process the mouse click? Ie. Where is the first "mouse is clicked!"
message go? To the parent dialog (hDlg in my case)? Or direct to the
child dialog which contains the combobox?

Does "standard" Windows programming practice require us to forward
messages from parent to child, or is this supposed to be automatic?

Sorry for the barrage of questions everyone... I'm just trying to learn.

------------------
Bernard Ertl

**Eric Pearson** · 27 Feb 2001, 03:55 PM

[I composed this before I saw your last message. I'm going to post this and then respond to your other questions.]

Bern --

I have discovered what I believe to be a major clue.

At the top of all of the CALLBACK FUNCTIONs in the program you posted above, add SLEEP 500. This will have the effect of allowing you to see what Windows is doing, step by step, but (of course) you will have to be very patient to watch the test work.

When the program starts up you will see Windows draw the dialog border, title bar, etc. Then it will draw the tab control, and finally the dialog that contains the grid.

Click on a combo box, then minimize the app. When it is completely done minimizing (when the Task Bar button loses the "depressed" look) click the Task Bar button and watch carefully. The app will un-minimize, the dialog border and title bar will be drawn, and then the grid will be drawn (!) and then the tab control will be drawn on top of the grid. The grid control is being redrawn, it is simply happening in the wrong order.

Stranger and stranger...

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

**Eric Pearson** · 27 Feb 2001, 04:13 PM

Bern --

> What do you mean by "dialog based windows"?
> What other type of window would you use the
> Spread control with?

Well, there are windows and then there are windows...

It is possible to create a non-dialog window by using the CreateWindow API function. It is relatively complex to do it that way, compared to using dialogs... You have to define and register a window class and then use CreateWindow to create an instance of that class.

The (several) Windows Dialog API functions (CreateDialog, CreateDialogParam, etc. etc.) create windows of the "dialog" class, which is a standard, widely used class. It's so standard that it uses the number 32770 instead of a name. Whenever a CreateDialog... or DialogBox... API function is used, Windows creates a dialog box.

Dialogs are "real" windows, they are just windows of a predefined class. I have never encountered any problems using dialogs, and in spite of what Farpoint support told you, I'm not aware of any problems that are caused by using dialogs that are children of other dialogs.

> Every control and every dialog is a window of
> some sort, right? They just have different
> properties, no?

Exactly!

> I'm assuming that the Spread control itself is a
> dialog window

No, it is a window of the class "fpSpread30", which is automatically registered by the Spread DLL's LibMain function when the DLL is loaded. It is not a dialog.

> When I click on the combobox cell in Spread
> control, how does Windows process the mouse
> click?

The combobox gets the click first. If it handles it, that's as far as the message goes. If it doesn't, it gets passed to the parent window, and so on, until it gets handled or discarded. (That's an over-simplification, actually, because each window class has a default message handler that handles many routine messages like clicks.) For more information, I recommend a good API-level book like Petzold.

> Does "standard" Windows programming practice
> require us to forward messages from parent to
> child, or is this supposed to be automatic?

It is 100% automatic.

HTH.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited February 27, 2001).]

**Borje Hagsten** · 27 Feb 2001, 04:23 PM

Hm, maybe the fact that you use both %WS_EX_CONTROLPARENT and
%DS_CONTROL styles in same dialog can cause some conflicts here?

From win32api.hlp:
WS_EX_CONTROLPARENT: Allows the user to navigate among the child
windows of the window by using the TAB key.
DS_CONTROL: allows the user to tab among the control windows of a
child dialog box, use its accelerator keys, and so on.

Sort of do the same thing, those two, so under same roof, conflicts
that effects other functions, like redrawing, maybe can happen. (?)
What happens if you remove the %WS_EX_CONTROLPARENT style from the
main dialog? Long shot, I know, but anything is worth trying..

(forget it. Just saw you already tested that..)

------------------

[This message has been edited by Borje Hagsten (edited February 27, 2001).]

**Bern Ertl** · 27 Feb 2001, 04:48 PM

Eric, nice trick with the SLEEP!

Perhaps the spread/grid is messing with the Z order?

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited February 27, 2001).]

**Bern Ertl** · 27 Feb 2001, 05:00 PM

Borje, I just retested the WS_EX_CONTROLPARENT & DS_CONTROL.

When I removed the WS_EX_CONTROLPARENT, there was no apparant
difference. The tab key still cycled focus from the tab control
to the spread control on the child window and back. The comboboxes
still did not refresh the background.

When I replaced the WS_EX_CONTROLPARENT and removed the DS_CONTROL
from the child windows, the tab key cycled from the tab control
through the controls on the child window, but NOT back to the tab
control. The combobox still did not refresh the background.

------------------
Bernard Ertl

Announcement

Tab key behavior with tab control

Tab key behavior with tab control

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment