Feature #3291
implement SYSTEM-DIALOG-COLOR
100%
Related issues
History
#1 Updated by Ovidiu Maxiniuc almost 7 years ago
- Status changed from New to WIP
- Start date deleted (
04/27/2017)
The full-syntax construct like this:
SYSTEM-DIALOG COLOR color-number UPDATE OKpressed IN WINDOW CURRENT-WINDOW.
will be converted in java as:
ColorTable.createColorChooserDialog(colorNumber)
.update(okpressed)
.setWindow(currentWindow())
.execute();
Notes:
- the static method call handles the mandatory parameters;
- each non-static method call (except
execute) from the chaining represents an option that sets up the server-side configuration of the statement; - finally, the
executemethod does the actual call on client side that will open the chooser dialog, based on options selected.
#2 Updated by Greg Shah almost 7 years ago
It looks good. Go ahead with this approach.
#3 Updated by Ovidiu Maxiniuc almost 7 years ago
- Related to Bug #1830: implement SYSTEM-DIALOG-GET-FILE support added
#4 Updated by Greg Shah over 6 years ago
The runtime implementation for this task was written in branch 1830b and was merged to trunk as revision 11188.
There are 2 known bugs to be resolved:
- Fill-ins for entering values directly are not working.
- After the the user makes a selection, the selection will be used by widgets that are subsequently created, but already existing widgets are not updated.
From Ovidiu in regard to the second issue:
This is because we cache gc/gf resolvers, I think. If so, we need to drop these caches and always get the values from FontTable/ColorTable. If this is not the reason, then we have to implement some notification to let the widgets know the FontTable/ColorTable were altered and need to be repainted or even redo the layout - since new fonts may have different metrics. These changes may have a really big impact in all GUI code.
#5 Updated by Greg Shah over 6 years ago
After the the user makes a selection, the selection will be used by widgets that are subsequently created, but already existing widgets are not updated.
In the 4GL all existing widgets immediately honor any changes to the COLOR table?
#6 Updated by Ovidiu Maxiniuc over 6 years ago
Greg Shah wrote:
After the the user makes a selection, the selection will be used by widgets that are subsequently created, but already existing widgets are not updated.
In the 4GL all existing widgets immediately honor any changes to the COLOR table?
I have done some investigations. It seems that the problem in the implementation of COLOR-TABLE:SET-RGB-VALUE(idx, rgb) which is used by the color chooser dialog to set the color after the user selects it.
In P4GL, the following code will instantly change the background color of the frame and its text to red/cyan:
DEFINE BUTTON prog-button LABEL "PROG".
FORM
"some text" SPACE(2) prog-button
WITH FRAME color-frame NO-LABELS TITLE "Update colors ..."
FGCOLOR front-color BGCOLOR back-color VIEW-AS DIALOG-BOX.
ON CHOOSE OF prog-button IN FRAME color-frame DO:
COLOR-TABLE:SET-RGB-VALUE(8, RGB-VALUE(255, 64, 64)).
COLOR-TABLE:SET-RGB-VALUE(9, RGB-VALUE(0, 196, 196)).
END.
The same code in FWD will only update the the color table entry, followed by a synch operation with the client. This is not enough to change the color of the already rendered widgets.
#7 Updated by Greg Shah over 6 years ago
The same code in FWD will only update the the color table entry, followed by a synch operation with the client. This is not enough to change the color of the already rendered widgets.
Can we easily know then the color table changes on the client? If so, can we force some kind of reload of all color resolvers (and then force a redraw of all visible windows)?
#8 Updated by Eric Faulhaber about 6 years ago
- % Done changed from 0 to 100
- Status changed from WIP to Closed
- Assignee set to Ovidiu Maxiniuc
Branch 1830c was committed to trunk as r11240.