Project

General

Profile

Feature #3290

implement SYSTEM-DIALOG-FONT

Added by Greg Shah about 7 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ovidiu Maxiniuc
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD

Related issues

Related to User Interface - Bug #1830: implement SYSTEM-DIALOG-GET-FILE support Closed

History

#1 Updated by Ovidiu Maxiniuc almost 7 years ago

  • Status changed from New to WIP
  • Start date deleted (04/27/2017)
Added conversion support in task branch 1830a, revision 11159.
The full-syntax construct like this:
SYSTEM-DIALOG FONT font-number
   ANSI-ONLY
   FIXED-ONLY
   MAX-SIZE 9 + 4
   MIN-SIZE 10 - 3
   UPDATE OKpressed
   IN WINDOW CURRENT-WINDOW.

will be converted in java as:
FontTable.createFontChooserDialog(fontNumber)
         .ansiOnly()
         .fixedOnly()
         .setMaxSize(plus(9, 4))
         .setMinSize(minus(10, 3))
         .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 execute method does the actual call on client side that will open the chooser dialog, based on options selected.

#2 Updated by Ovidiu Maxiniuc almost 7 years ago

  • Related to Bug #1830: implement SYSTEM-DIALOG-GET-FILE support added

#3 Updated by Greg Shah almost 7 years ago

I like the approach. Go ahead with this.

#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 FONT table?

#6 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.

Also available in: Atom PDF