New FWH 11.07

[mgsoft]

Mr. Nao,

Code: Select all  Expand view

2. This requires that group boxes be defined prior to the controls within the group box ( in rc files, the tab order should be changed accordingly)
3. All group boxes in the rc file should be redefined in the program. They should not be left undefined.
 

Point 2 requires revising all .rcs and point 3 requires to revise all source code. Is not there any other solution?.

Now we should revise all rcs and prgs to see if whe use group boxes?. In my case, it does not worth updating FWH at all.

[Antonio Linares]

Mgsoft,

Now we should revise all rcs and prgs to see if whe use group boxes?. In my case, it does not worth updating FWH at all.

Is such a big effort to use a source code editor to make an automatic search for GROUP keyword ?

Your comments are really an offense to all the hard work that we are doing to offer our best code. Feel free not to upgrade, much better, you should migrate to another tool and stop using FWH. Certainly it is not a tool for you.

[mgsoft]

Antonio,

I am sorry but you misunderstood me. I was not blaming for your work, only expresing my point of view, as I do not REDEFINE Groups in my source and it is a very big application, so I can´t open the 350 prgs and search for GROUP. I put it in the .rc file.

[Antonio Linares]

You can easily edit your RC files using your source code editor and search for GROUP.

Is it that hard ???

[byte-one]

Now i checked the changes above and found out:
1. Un-redefined says outside of a group are not transparent now
2. In gets with spinner the spinner-arrows or in xbrowse the bars are not visible at beginn if the get or xbrowse inside a group
3. Groups are only transparent, if a brush in the dialog is using. If i use only clausula COLOR... in the dialog, the groups are not transparent.

[mgsoft]

Antonio,

I mean I don´t redefine groups in my code, they are just static on .rc files:

GROUPBOX "", -1, 12, 80, 252, 128, BS_GROUPBOX
LTEXT "Datos Médicos", 300, 118, 95, 136, 12
[...]

So now I would have to assing each groupbox a new ID and redefine it in each dialog. That´s what I am refering to.

[James Bott]

I know I have mentioned this before, but wouldn't it solve a lot of problems if all controls were transparent by default? I still can't think of any reason one would want a control that wasn't transparent. Existing code wouldn't break--at least I can't think of any situations where it would.

Comments?

Regards,
James

[Antonio Linares]

James,

A SAY with a different background color is a possibility, in that case it should not be transparent

[James Bott]

>A SAY with a different background color is a possibility, in that case it should not be transparent

But since that is the rare case, it could easily be coded. All others would work without any extra coding.

I was not saying that we shouldn't have the capability of defining a non-transparent control, just that having the default transparent would eliminate a lot of coding and problems.

Regards,
James

[nageswaragunupudi]

I know I have mentioned this before, but wouldn't it solve a lot of problems if all controls were transparent by default? I still can't think of any reason one would want a control that wasn't transparent. Existing code wouldn't break--at least I can't think of any situations where it would.

Comments?

Regards,
James

The present implementation is also very simple.
If a dialog is defined as TRANSPARENT, all controls on the dialog (with obvious exceptions of browses) are automatically treated as transparent. It works the same way as you proposed.

(Actually when a dialog is declared as transparent, it does not mean the dialog is transparent, dialog by itself is opaque, but that the controls on the dialog are to be painted transparently)

The programmer has the choice to define the dialog as transparent or not. If he defines the dialog as not transparent, then he can choose which controls should be transparent or not.

I think this is the best and simplest way.

This does not apply to Windows because windows do not have transparency attribute.

[Antonio Linares]

We have just published a revised FWH 11.07 that seems to have solved the issues reported

Thanks to everybody for the great feedback!

[byte-one]

Antonio, now the dialogs not to be set to "Clip Children"? And the dialogs flickering if i click on radio or checkbox!

[nageswaragunupudi]

Antonio, now the dialogs not to be set to "Clip Children"? And the dialogs flickering if i click on radio or checkbox!

I have just downloaded and testing.
Clip children is not needed. Same old rc files should work.

[nageswaragunupudi]

I have tested Mr. Maurizio's sample for transparency of groups and statics. The sample is working well.

I have tested checkboxes and statics with the following sample. Working well.

Code: Select all  Expand view

#include "fivewin.ch"

function Main()

   local oDlg, oFont, oSay
   local lVar  := .t.

   DEFINE FONT oFont NAME 'TAHOMA' SIZE 0,-12
   DEFINE DIALOG oDlg RESOURCE "TESTDLG" FONT oFont TRANSPARENT

   REDEFINE SAY oSay PROMPT "SECOND LINE" ID 4002 OF oDlg

   REDEFINE BUTTON ID 4009 OF oDlg ACTION MsgInfo( 'ok' )

   ACTIVATE DIALOG oDlg CENTERED

return nil
 

rc file

Code: Select all  Expand view

LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US

TESTDLG DIALOG DISCARDABLE 6, 18, 266, 134
STYLE WS_POPUP|DS_MODALFRAME|WS_CAPTION|WS_SYSMENU|WS_VISIBLE
CAPTION "Dialog"
{
  CONTROL "OK", IDOK, "Button", WS_TABSTOP, 148, 108, 45, 15
  CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 204, 108, 45, 15
  CONTROL "This is some static text", 4001, "Static", WS_GROUP, 12, 12, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Second Line Static Text", 4002, "Static", WS_GROUP, 12, 32, 100, 12, WS_EX_TRANSPARENT
  CONTROL "Sample Check Box", 4003, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 16, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Second Check Box", 4004, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 116, 40, 92, 12, WS_EX_TRANSPARENT
  CONTROL "Radio-1", 4005, "Button", BS_AUTORADIOBUTTON, 124, 60, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Radio-2", 4006, "Button", BS_AUTORADIOBUTTON, 124, 80, 56, 10, WS_EX_TRANSPARENT
  CONTROL "Inside Group", 4007, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 20, 68, 80, 16, WS_EX_TRANSPARENT
  CONTROL "This is a Group", 4008, "Button", BS_GROUPBOX, 8, 56, 92, 44, WS_EX_TRANSPARENT
  CONTROL "Test", 4009, "Button", WS_TABSTOP, 12, 108, 50, 14
}
 

[gkuhnert]

Hi,

when using a <<program.exe.manifest>> - file I still have problems when my mouse hovers over a checkbox with the checkbox itself gets bold. Also the flickering still is of a little disturbance.
BUT: I found a solution for both problems and I hope I'll get feedback if someone thinks there might be side-effects to the changes I made.

You can test the described problems like this: (save this to a file named after your .exe-File with a .manifest behind the .exe, for testfx8 you'll name it testfx8.exe.manifest)

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
   <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
   </dependentAssembly>
  </dependency>
</assembly>
 

1) To avoid the text getting bold
therefore I needed to define '#DEFINE UPTO_FWH1105' in control.prg. Now I can go over my checkboxes with the mouse without the checkboxes getting bold. However, I don't know, which side-effects it might have, because I only did a quick test.

2) To avoid the flickering
therefore I denied refreshing at WM_LBUTTONDOWN in case of Themed Apps using TFolderEx in method HandleEvent (also in control.prg):

Code: Select all  Expand view

     case nMsg == WM_LBUTTONDOWN
           if ::lTransparent .and. ( ::IsKindOf( "TRADIO" ) .or. ::IsKindOf( "TCHECKBOX" ) )
                  if !(isAppThemed() .and. ::oWnd:oWnd:Classname() == "TFOLDEREX") // gilbert new
                      // ::oWnd:Refresh( .f. )
                     ::oWnd:Refresh()  // RevBuild 11.07: Refresh(.f.) replaced to avoid overpainting of says
                  endif
           endif
           return ::LButtonDown( nHiWord( nLParam ), nLoWord( nLParam ), nWParam )
 

I hope this doesn't have any side-effects either.