Bug #5989
MESSAGE SET: empty string is treated as undefined
50%
History
#1 Updated by Vladimir Tsichevski over 2 years ago
Run the following code:
DEFINE VARIABLE charVariable AS CHARACTER FORMAT "x(128)" NO-UNDO. MESSAGE "Enter text: " SET charVariable. MESSAGE "Value: " charVariable " undefined? " (charVariable = ?).
Press ENTER without entering any text.
In OE the empty string is assigned to the variable.
In FWD an undefined value is assigned instead.
#2 Updated by Vladimir Tsichevski over 2 years ago
- File message-set.p
added - Status changed from New to WIP
- Assignee set to Vladimir Tsichevski
Also: the value visible in the fill-in for MESSAGE SET statement differs from that in FWD for logical and number variables:
- in OE the fill-in is either empty or a format mask is visible (for date and datetime variable types)
- in FWD the default value is visible (as completely selected text):
0for number types,nofor logical.
A test program message-set.p is attached.
#3 Updated by Vladimir Tsichevski over 2 years ago
- % Done changed from 0 to 50
The original issue fixed in 3821c rev. 13419. Please, review.
#4 Updated by Vladimir Tsichevski over 2 years ago
- File 5989-2.diff added
Vladimir Tsichevski wrote:
Also: the value visible in the fill-in for
MESSAGE SETstatement differs from that in FWD for logical and number variables:
- in OE the fill-in is either empty or a format mask is visible (for date and datetime variable types)
- in FWD the default value is visible (as completely selected text):
0for number types,nofor logical.
The direct solution may be that in 5989-2.diff: use different defaults for fill-in editors. I do not know, will it break anything else or not yet. Please, review, to tell me if I am moving in the right direction.
#5 Updated by Greg Shah over 2 years ago
Code Review Task Branch 3821c Revision 13419
We should have an API in BaseDataType to assign the default value without needing the caller to provide any value (e.g. public abstract void assignDefault()). That would be a cleaner approach that would allow the default value processing to be hidden inside each wrapper type. Still, the current change is OK.
#6 Updated by Greg Shah over 2 years ago
Code Review 5989-2.diff
We must not make changes to return unknown value from that method. The contract of that method explicitly defines that the default value will be returned. The breakage would be severe.
I think the real changes would be confined to Window.message(String, boolean, BDT, boolean, String, Color) or "downstream" of that. This is a behavior that is specific to the MESSAGE SET, not something that should modfify all editing behavior for widgets.
If this is not needed for a customer project, please defer further work.
#7 Updated by Vladimir Tsichevski over 2 years ago
Greg Shah wrote:
Code Review 5989-2.diff
We must not make changes to return unknown value from that method. The contract of that method explicitly defines that the default value will be returned. The breakage would be severe.
Yes, this was just as an illustration of the idea.
I think the real changes would be confined to
Window.message(String, boolean, BDT, boolean, String, Color)or "downstream" of that. This is a behavior that is specific to theMESSAGE SET, not something that should modfify all editing behavior for widgets.
May be, you are right. It would probably lead to some code duplication.
If this is not needed for a customer project, please defer further work.
I'll create another task for the remaining issue and close this one, since the original issue is fixed already, OK?
#8 Updated by Greg Shah over 2 years ago
I don't think that is needed. We already have useful discussion here that is best to stay together with the future work.
#9 Updated by Vladimir Tsichevski over 2 years ago
Greg Shah wrote:
I don't think that is needed. We already have useful discussion here that is best to stay together with the future work.
OK, will leave this task in the current state.