Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 20 JAN 2004 05:01:23PM Mark B wrote:

Hi All,

On both 4.1.2 and 4.1.3 we have instances where at times radio buttons do not appear on the window when they should. If you click on the area where the radio buttons should be, then that will often rectify the problems.

Sometimes this will make the whole set visible, other times it will just make the selected option visible.

It seems it may be restricted to when the radio buttons appear within a group.

I have just created a form with about 6 controls on it and it happened there, so it's not a too many controls issue.

We do know we had a similar thing occurring in 16 bit but we thought that it would be rectified with 32 bit.

Is this a known bug? Is there something we can do to prevent this?

Thanks,

Mark


At 21 JAN 2004 06:41AM Oystein Reigem wrote:

Mark,

The problem as I remember it was that one or more options at the bottom disappeared. (I only saw it in vertical radio groups.) Both button and label went away. Is that what you see?

In Don Bakke said he thinks this was a OI16 problem.

In case your problem is different: The thread has postings from me that mention other peculiarities I've seen.

- Oystein -


At 21 JAN 2004 11:59AM Colin Rule wrote:

How long is the text in your radio buttons?

I have seen this only yesterday on OI16, and it was caused by resources with long text in the radio control.

I think it is more to do with OI's naming of the control, eg WINDOW.RADIOGROUP.RADIOTEXT

The user gets to choose the name of the group control, but then creates each radio button as a separate control based on the name of the text label in the control, and this is where I think the problem with resources lie.

You could try making the radio button names shorter, and then place a static to the right for the rest of the text, or even, display a brief description of the radio buttons function when the selection is changed.

Another alternative is to make them check boxes instead, and code it so that only one can be checked at any time, and the others are turned off. A fudge I know, but it is a good way of working.

My best guess is to make the names shorter.

Another solution, would be to give the names of the radio buttons the same as the values, then programatically put in the text when the form is created, this way you get long names, but short control names, and therefore dont have the resource issues.

The problem that this makes is that the radio controls do not expand to suit the length of the text you have, so you have to resize them manually.

I can give you the code for this it you want it, if so please post here and I will copy/paste a new response.

Colin


At 21 JAN 2004 07:48PM Mark B wrote:

Great thread, Thanks Oystein.

Now I want to play around with moving radio buttons.

I don't know why I would use it, just want to see it happen I guess.

Also I think you were probably right about missing just lower options in 16 bit. However in 4.1.2 and 4.1.3 we are missing entire radio groups.

Strange.


At 21 JAN 2004 07:56PM Mark B wrote:

Colin,

We were thinking along the same lines, that it is probably related to the individual naming of the controls. In the most recent example we had though, the labels were only Days, Weeks, Months, Years and the values were single characters. And this is in 4.1.3.

Curiously, this is how we seem to have rectified it. We make the window invisible in design mode. Upon the create event we call a routine that does very little except centre the window and then make it visible. When the window becomes visible, all the controls are also visible. I don't know if there is any real answers there but it works for us.

Thanks for your help

Mark


At 21 JAN 2004 08:30PM Donald Bakke wrote:

Mark,

Is your radio button group inside of a groupbox?

[email protected]

SRP Computer Solutions, Inc.


At 22 JAN 2004 04:13PM Mark B wrote:

Yep


At 22 JAN 2004 05:33PM Donald Bakke wrote:

Does removing the groupbox help at all? We have seen similar behavior when groupboxes are mixed with radiogroups. However, this has been when groupboxes are being programmatically moved around.

[email protected]

SRP Computer Solutions, Inc.


At 29 JAN 2004 09:53PM Mark B wrote:

Removing the group box does help, in that the radio buttons appear. However, without the group box, the layout doesn't suit.

We will continue using the centre window functionality while it works.

Thanks


At 30 JAN 2004 01:16AM Donald Bakke wrote:

Mark,

This may be a bit much, but if you could make this window stand-alone (i.e. no table binding) and want to send me a check-out or RDK I'd be happy to look at it. You have me curious.

[email protected]

SRP Computer Solutions, Inc.


At 30 JAN 2004 03:27AM The Sprezzatura Group wrote:

There's code in the system that affects what's inside a group box. Depending on what the VISIBLE and ENABLED properties of the group box are, these will 'leak' down to the controls inside of it.

Also, remember there are Option+1 controls for the radio group, one for each button, plus one for the group itself.

We've seen strange things if the control is sized slightly outside of the group box. We've also seen strange things based on tab order, which effects redisplay order.

The centering would resolve the repainting issues, since size forces all controls to redraw. You might want to send a redraw message to the window, or the radio controls, or just reset it's visibility.

The Sprezzatura Group

World Leaders in all things RevSoft


At 30 JAN 2004 03:46AM The Sprezzatura Group wrote:

There's code in the system that affects what's inside a group box. Depending on what the VISIBLE and ENABLED properties of the group box are, these will 'leak' down to the controls inside of it.

Also, remember there are Option+1 controls for the radio group, one for each button, plus one for the group itself.

We've seen strange things if the control is sized slightly outside of the group box. We've also seen strange things based on tab order, which effects redisplay order.

The centering would resolve the repainting issues, since size forces all controls to redraw. You might want to send a redraw message to the window, or the radio controls, or just reset it's visibility.

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/c8947e5d86ec042e85256e210078fa1a.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1