FiveTech Software tech support forums

I still have a problem with checkboxes. On some dialogs, but not all, a checkbox requires a double click to change the value. On others, it takes a single click.

The problem is consistent on a dialog, but does not apply on all dialogs. A dialog with the problem may have two or three checkboxes, and they all require a double click. However, on another dialog they may work fine with a single click.

The controls are defined in an RC file and they are identical ( except for the coordinates ).

The REDEFINE CHECKBOX is the same in all cases.

This problem occurs in Versions 10.7 through 10.10, but not in 10.6.

No, I cannot build a simple sample that reproduces the problem, but when it occurs, it happens on all computers regardless of the OS.

I'd appreciate any ideas on what I might check for this problem. The application is themed, and I'm testing on Win 7 using FWH 10.10 and xBuilder ( xHarbour ) latest stable version.

Thanks for any ideas on where I might look.

Tim

Her is some further information on this problem.

If I link in the source from Control.prg dated 06/2010, the problems go away. So I did a comparison and found that there are three differences:

lTransparent is INIT as .f. and my application does use transparent dialogs

The control now uses a function IsKindOf( ) for folders and checkboxes. Where is this from and could it be giving a bad read ?

In HandleEvent( ) lTransparent is referenced and must be true for the checkbox to respond to the left mouse click. Again, I'm wondering if there is a problem with the lTransparent value sometimes ?

In summary, the problem is the result of changes in the control class ( not the checkbox class ) that occured in July 2010. Those changes seem to be exclusively with focus and transparency.

Any thoughts / suggestions ?

Tim,

Could you please post here the portion of your code where you use the checkbox ?

Does it have a VALID ? or a WHEN ? Does it have an ON CHANGE clause ?

thanks

Here is an example:

REDEFINE CHECKBOX oInvr:invcof ID 750 OF oDiw MESSAGE "Does this part have cores attached ?" UPDATE
REDEFINE CHECKBOX oInvr:invtxf ID 749 OF oDiw MESSAGE "Is this part generally taxable ?" UPDATE
REDEFINE CHECKBOX oInvr:invtyp ID 748 OF oDiw MESSAGE "Is this a stocking part ?" UPDATE

And the .rc controls:

CONTROL "Core", 750, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 80, 220, 40, 13
CONTROL "Tax", 749, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 26, 205, 40, 13
CONTROL "Stock", 748, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 26, 220, 40, 13

With 10.06, they work fine. With 10.07-10.10, they require a double click !

Hi.

My problem with checkboxes is a bit different and not as critical.

The first time you click it, the whole dialog flickers. Further clicks on the check box won't cause the flickering. But it is only doing it on one particular dialog. I tried to build a reduced self-contained sample with the exact same code and resource but can't reproduced the behavior.

Reinaldo.

Reinaldo,

According to the What's New for ver 10.10 this has been fixed.

viewtopic.php?f=16&t=20166#p106713

Regards,
James

Tim,

CONTROL "Core", 750, "Button", BS_AUTOCHECKBOX|WS_TABSTOP, 80, 220, 40, 13

I note that when I create a default style checkbox in Workshop it looks like this:

CHECKBOX "Checkbox", IDC_CHECKBOX1, 88, 20, 60, 12, BS_AUTOCHECKBOX | WS_TABSTOP

Are you using a different resource editor, or do you use a different type of control for a reason?

Regards,
James

James,

I actually don't use a resource editor anymore. I do all my fine tuning "by hand". However, "Button" is correct and works. I think we were given that guidance when we first went to themes.

Of course, the issue still comes back to the shift in code from 10.06 to 10.07.

Tim,

Please modify your RC as James has suggested you. That may be the reason of the problem

I tried that and got an error ! Also, it works fine with 10.06 but not 10.07 plus.

Tim,

What was the error?

James

The error when trying to compile is "String literal expected"

Tim, I think that such an approach is very time consuming and inconclusive. The right way to rapidly solve the issue is to make a reduced and self-contained sample showing the problem.

EMG

Enrico,

If it was reproduceable ( consistent in all areas ) I would do that as I have in the past.

In this case, it is reproduceable only in the much larger code of the application ... some places it works, some it doesn't. Again, it works perfectly with 10.6 but not 10.7 and beyond.

I have also isolated it to the control.prg and listed the areas where there is a code change ! If I could make a small code to show it, I would. However, someone made the changes to the control class in the July release, and knows what else might be involved. If I simply put in the 10.6 code the problem goes away !

If I can't reproduce the problem how can I fix it? Anyway, can you check the value of ::lTransparent inside of HandleEvent() method (write its value to a log)?

EMG