Maybe a bug

[Mark Strickland]

I have a program with multiple forms.  On several forms I change a label background color to reflect the current search key that is selected.  I use the standard FF function to change color:

Code Select Expand


FF_CONTROL_SETCOLOR (HWND_FORMTABLESSIG_LABELCOL1, -1, %coloryellow)
FF_CONTROL_SETCOLOR (HWND_FORMTABLESSIG_LABELCOL2, -1, %colorlightblue)


All of the older forms work correctly but I have a problem when I added this new form.

I added this code to a new form and when the form is first displayed these two controls are "gone".  These two statements are in part of the code to display the intial screen.  If I minimize the program with the system minimize button (upper right) and bring it back the labels appear 100% correctly.

If I do NOT minimize first and use the program in the way that causes these statements to change the color again the controls appear but they do not have any border but the color is correct.  The border property is set at design time.

Is there a way to force the repaint of these to work around this issue.

Any thoughts.

Thanks.

[TechSupport]

Maybe try FF_Control_Redraw  ?

Please let me know if it doesn't fix the problem.

[Roger Garstang]

Might be good to know where this code is used too...sometimes I have problems when messing with colors/sizes in WM_CREATE before the window is shown...and some messages like WM_SIZE and such fire before the control is created, etc.

[Mark Strickland]

The FF_REDRAW does not change the appearance.  I also tried FF_SHOWSTATE but no difference.  The appearance is sort of "grayed out".  No border, no text, and the background color of gray.

I played a bit and if you pop any other window and move it over the control it repaints for the portion you "wipe over".  If you "wipe over" only part of the control the part you touched now appears as you move off of where you wiped.

There is one difference from the others in the project that work.  This is the only form so far that is a tab control on a tab control where I am changing the color on the fly.  The others are on a tab control only one level deep.  I will have a second one ready shortly that will be tab on tab and we can see if it has the same symptoms.

I will update you on that result.

If it is a tab on tab problem you can probably duplicate this easily.  The control that I am changing is actually a label (if that makes any difference).

I can live without this but it would be nice to find a workaround.  The design time format settings work fine and the background color and border appear so long as I don't change the background color on the fly.

Thanks.

[Mark Strickland]

To Rogers point this is in a function I built that is called from a standard FF event of KILL FOCUS on a TextBox.

[Roger Garstang]

Perhaps it is a ReDraw Class style for the Form, or a ClipChildren/ClipSibling thing.  Do the Labels overlap other controls or anything...and what styles does the form they are on have- both Window and Class styles.

[Roger Garstang]

Well, that rules out it being a problem with WM_CREATE or anything...how about the color of the controls at design time?  What color are they since the Kill Focus may not happen at app start?

[Mark Strickland]

I made sure that the controls did not overlap any other controls or were sourrounded by a frame.  I use frames for some cosmetic purposes on some forms to create a visual grouping.  On the forms where this does work (not on nested Tabs) the controls touch (end of control 1 is on the same pixel position as the beginning of the next).

I played with the CLIP CHILDREN/SIBLING settings but no difference.

I played with setting foreground only or both foreground/background and no difference.

I have some TextBoxes as well as these Labels that have a similar problem.  If you set the background then the control "disappears".  You can still "wipe" over it as previously described.  If you change the foreground color the text will now appear but the typical 3d border I use does not re-appear.  Again the "wipe" thing makes it all normal.

I have not yet tried to FF_CONTROL_REDRAW the TAB control but I will.

[Mark Strickland]

If I do a FF_CONTROL_REDRAW on the second level tab control after setting the colors on the label controls in question most of the controls on the whole tab "disappear" --- worse.  The "wipe" thing still fixes what is missing.

There are more options to to mix and match with the CLIP settings on the tab controls, etc but, in the interest of time, I think need more advice at this point rather than "random" experiments.

Thanks.

[TechSupport]

Do you have the WS_CLIPCHILDREN style set for your TabControl and TabControl child Forms??? Setting that style will prevent the form from overdrawing your child controls.

[Mark Strickland]

Several Strange Things - If you are old enough you will remember the TV show in the US called Twilight Zone - Unexplained things

Well ---

I built a test project with a Tab on Tab and it works just fine.  I noticed something different.  The test project had no title bar in the designer on the sub-form that was the content of the tab.  My "real" project (a huge one) showed a Windows title bar on the top of each sub-form in the designer.  I looked at the sub form for each tab and they did have the TabControlChild set TRUE.  I reset the property to TRUE (not FALSE first) and the Windows title bar went away.   Twilight Zone Problem #1.

The "real" project has both TextBoxes and Labels where I change colors.  On the Tab on Tab nested form both the TextBox and the Labels "disappear" when the form is first displayed (click on that tab).  I have code in the first TextBox SetFocus to correctly default colors when you are at the "beginning" of the form.  If you click a tab to leave this form and click the tab to come back the TextBoxes display CORRECTLY but the labels never appear.  I have one other button on the form that does some processing and then changes the color of the TextBoxes text and if I click that when they are gone they reappear but WITHOUT a border.   Twilight Zone Problem #2.

I checked the CLIPCHILDREN setting on the form that holds the Tab control and the Tab content form.  The behavior above did not change.   Twilight Zone Problem #3.

I re-added the FF_CONTROL_REDRAW and it seems to have no effect either. TZP #4

Along the way changing all of these things severl times I exited FF and restarted it and reloaded the project before compiling.

Next idea???

Thanks.

[Roger Garstang]

I know the caption bars were removed from Tab forms in the last version so sizes would figure right...other than that no clue.  I haven't played with Tabs or Tabs on Tabs stuff in FF much.  When needed I usually made my own cause there has been so many changes to them, especially user specific changes that I didn't want anything messing them up.  XP Themes also do not work well with tabs, so I've tried to stay away from needing them at all.  I prefer the new style like Paul uses for the Options in FF now...wish he'd release that as an FF Control.

[Mark Strickland]

I fixed the problem with a workaround solution.

I first tried to do a FF_CONTROL_SHOWSTATE %show but nothing happend.  I then added %hide then followed by a %show and the problem is fixed.  So when I change color I just add the SHOWSTATE %hide then %show.

It is very odd that when I created a new project for testing it seems to work correctly.  The real project is one with over 800 controls and many tabs and sub-tabs.  It may be related somehow that it was built with the pre 2.5 FF and converted and the test one was created directly in 2.5.

Roger --- thanks for the clarification to the Window title.  I never really noticed before until I started trying to debug the problem.  I had not added any new tabs with the autosize feature since the update.

I really don't like not knowing why but after this many years working with Windows I will just added it to the "un-explained phenomenon list" with the other things.

Thanks.

[Roger Garstang]

I haven't dug in and saw how the FF_CONTROL_REDRAW command works, but I know each API has its strengths and weaknesses, have you tried other Win API to redraw it?  RedrawWindow is usually my favorite...if Paul doesn't use it and you find it works, he may need to change the FF Function to use it.  It does give a lot of options you'll really need to look at.  I'd try each combination to see how you want it.

Use RDW_UPDATENOW if you want it to be painted right away, RDW_ERASENOW just erases and Paints when the message loop is free.  If you send it to the window containing the controls, you'll need RDW_ALLCHILDREN...I'd just send it to the control's hWnd though.  You shouldn't need any of the validation flags, and you probably won't need RDW_FRAME if that narrows down things.  UpdateWindow is another API, but I usually only use it in a tight loop to update the screen/listview/listbox to help out with flicker.