Project

General

Profile

Bug #2293

check box default text

Added by Thomas Lynch over 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
10/07/2013
Due date:
% Done:

0%

Estimated time:

Description

Name : wt-devel

Arch : x86_64

Version : 3.3.0

Release : 2.fc19

on the prior Wt version if I did not at least specify a null string on a WCheckbox, it would not let me setText later, so I have a bunch of

check_box = new Wt::WCheckbox(""); // need to specify a string, or setText will be refused

in the code. Now with this version (specified above), if I give WCheckbox a null string a lot of weird behavior occurs. I'm getting Wt internal errors, and extraneous default box checking. All of this goes away if I provide a non-null string to the constructor:

check_box = new Wt::WCheckbox("why?"); // need to specify a non null string or bad things happen

man, and this was not obvious, took hours to find and prove this out ... finally found it by accident when messing with the constructors

#1

Updated by Koen Deforche over 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche

Hey,

Can you provide a test case which illustrates the bad behaviour? It's indeed the case that if you do create a checkbox without setting a text before the first rendering, you can't add any later since then we render the checkbox as a naked 'input' element. setText() will be ignored, but there shouldn't be any other bad behavior like you describe?

koen

#2

Updated by Thomas Lynch over 8 years ago

If I leave the checkboxes with just "" as the initial text, so that I can fill them in later, I get funny behavior described above. Just on a lark I set them instead to "#unitialized" and made a bool flag to note whether they had text, and the problems when away.

#3

Updated by Koen Deforche over 7 years ago

  • Status changed from Feedback to InProgress
  • Target version set to 3.3.4
#4

Updated by Koen Deforche over 7 years ago

  • Status changed from InProgress to Resolved
#5

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF