Activity
From 07/02/2019 to 07/31/2019
07/31/2019
- 07:29 AM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- Moved revision 11322 onto a new branch 3889a. Revisions 11320 and 11321 were merged into 4045a. Branch 3690a is no lo...
07/25/2019
- 03:30 PM Bug #3889: incorrect initial widget and screen values for combo boxes and selection lists
- > I have noticed that the INT values work for the SIMPLE and DROP_DOWN combo-boxes, despite the fact that in Progress...
- 12:52 PM Bug #3889: incorrect initial widget and screen values for combo boxes and selection lists
- I made some tests onto which I ran revision 11322 of branch 3690a. By now, I have included all combo-box sub-types: D...
07/24/2019
- 10:00 AM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- I think it makes sense to split these changes. Please merge the 11320 and 11321 revisions into 4045a.
Then create... - 08:35 AM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- Indeed, revision 11321 was meant to fully fix bug #3690, while revision 11322 is still work in progress. There should...
07/23/2019
- 04:23 PM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- Code review 3690a revisions 11321 and 11322. I'm good with the changes. Just please remove the commented out code in ...
- 10:17 AM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- Yes, revision 11321 of 3690a fixes the points mentioned and it is ready for review. Last reviewed revision was 11320.
- 10:05 AM Bug #3690: BUTTON widget reaction on SPACEBAR and ENTER keys
- Adrian, do the changes in 3690a revision 11321 represent your fixes for the code review items? If so, is it ready fo...
- 10:02 AM Bug #3889: incorrect initial widget and screen values for combo boxes and selection lists
- Code Review Task Branch 3690a Revision 11322
1. For @ComboBoxWidget@, @GenericWidget@ and @GenericFrame@, we know...
07/16/2019
- 01:33 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Task branch 4130a was rebased from trunk rev 11326. The latest revision is now 11327.
- 12:52 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- I am going to rebase 4130a now. Do not make any changes to 4130a.
- 12:52 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Code Review Task Branch 4130a Revision 11321 and 11322
I've fixed the issues in items 1 and 2 as revision 11323.
... - 11:17 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- after uncommitting, branch 4130a got into inconsistent state. So I recreate all changes of the branch 4130a in the br...
- 09:44 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Code Review Task Branch 4130a Revisions 11324 and 11325
Functionally, I'm OK with trying these changes.
1. Plea... - 09:07 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- As noted previously, you MUST NOT merge changes from trunk into your branch. We have a very specific rebasing proces...
- 07:28 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- changed the fix to ArrayIndexOutOfBoundsException, now all uast/format_string tests passed. I pushed all fixes relate...
07/15/2019
- 07:55 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- I added format and data to recreate a situation when @missing>0@. This caused an @ArrayIndexOutOfBoundsException@ in...
07/12/2019
- 11:02 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- @missing > 0@ is being used to track the condition where all of the following are true:
* the result must be right... - 08:35 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> Please fix it as well. Use 4130a as the branch.
I found the reason of the wrong alignment:
...
07/11/2019
- 10:22 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > I discovered that so called floating-decimal display format in string mode works different in FWD and 4gl:
string(... - 12:52 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> I am OK with trying the change from @splitFormat@ to @rightAligned@. You can put it into branch ...
07/09/2019
- 02:10 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- I am OK with trying the change from @splitFormat@ to @rightAligned@. You can put it into branch 4130a. Does it fix ...
- 11:42 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> Yes, you are looking at the wrong process. As noted in #3691-67:
>
> > As discussed in the "... - 09:42 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Yes, you are looking at the wrong process. As noted in #3691-67:
> As discussed in the "Runtime Architecture":/p... - 09:37 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> No. Are you debugging the FWD client?
I an debugging the FWD server. - 09:35 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- No. Are you debugging the FWD client?
- 09:27 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> Set breakpoints in @FillIn.processKeyEvent()@ and @FillIn.draw()@. Then follow the event process... - 09:22 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Set breakpoints in @FillIn.processKeyEvent()@ and @FillIn.draw()@. Then follow the event processing flow through the...
- 09:08 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> Look deeper that this set of classes. Look at @DisplayFormat.Presentation@.
I set breakpoin... - 05:28 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > Debugger stops at these breakpoints when the window is prepared, but does not stops when I edit the input fields.
... - 02:55 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> > They work while the window is initialized bot does not work when I edit the content of the fiel...
07/08/2019
- 03:46 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > They work while the window is initialized bot does not work when I edit the content of the fields.
Please explai... - 08:59 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> You can look inside @FillIn@ and @FillInGuiImpl@ to see how they are used.
Set a lot of brea... - 12:50 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- Greg Shah wrote:
> 3. Each file that is changed needs a history entry.
Done.
- 12:06 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- Greg Shah wrote:
> Code Review Task Branch 4130a Revision 11322
>
> 1. Please explain the logic behind your chan...
07/07/2019
- 10:10 PM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- Greg Shah wrote:
> 2. Running the ChUI regression testing can be used as a reality check.
How to run regression tes...
07/05/2019
- 09:43 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > Where in the FWD code is alignment chosen to place @screen-value@ attribute at the screen?
This was mentioned in... - 06:23 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- I have a question (see #3691-107).
The @dialog.p@ contains @roomRate2:screen-value = roomRate:screen-value.@. But ... - 08:33 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- Code Review Task Branch 4130a Revision 11322
1. Please explain the logic behind your change. On the surface it i... - 06:32 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- > But I would like to run it faster, as a junit test, using some simple wrapper:
com.goldencode.Launcher.launch(com.... - 04:55 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- made a fix in @secure/code/p2j_repo/p2j/active/4130a/@
Now the test @uast/format_string/abl/makeCheck.p@ shows full ... - 01:23 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- So I have a short (1 line) 4gl test program:
@display string(DECIMAL("-99.876"), "->>>.") skip.@
I converted it to ...
07/04/2019
- 01:37 PM Bug #3691: literal $ character in format appears on the right side of the fill-in
- My previous comments:
*the 4GL reference for "Data Types" may have something useful*
*see the NumberType and de... - 11:40 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Greg Shah wrote:
> > Anyone knows where this behavior is specified?
>
> Are you asking for where the 4GL document... - 11:38 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- But Eugenie's point is correct. The 4GL docs are incomplete and sometimes wrong.
- 11:37 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > Anyone knows where this behavior is specified?
Are you asking for where the 4GL documentation explains this (the... - 11:36 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Alexei Kaigorodov wrote:
> I have a question: if a decimal number has more digits after the point than the format al... - 11:26 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- I have a question: if a decimal number has more digits after the point than the format allows, then 4gl rounds that n...
- 11:01 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- > I could not found the rules which govern such alignment
If you have specific questions, post them here.
> an... - 05:51 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Filed a bug report #4130 "FWD truncates decimal part instead of rounding when displaying" which describes the reason ...
- 12:02 PM Bug #4135: high dpi screens display in low dpi
- A customer has reported that the web client renders in a low resolution when run using a high dpi screen (e.g. a MacB...
- 12:01 PM Bug #4135 (Test): high dpi screens display in low dpi
- 11:58 AM Support #4134: reduce the processing for calculated columns
- If FWD evaluates the expressions for a calculated browse column more than the 4GL, then we can speed things up by mat...
- 11:54 AM Support #4134 (New): reduce the processing for calculated columns
- 01:10 AM Bug #4130: FWD truncates decimal part instead of rounding when displaying
- the article [[https://knowledgebase.progress.com/articles/Article/000030560]] reads:
@FORMAT rounds the displayed ... - 12:54 AM Bug #4130 (New): FWD truncates decimal part instead of rounding when displaying
07/03/2019
- 06:16 PM Feature #4129: map web client users to OS accounts
- h2. Existing Approaches
The web client is designed with a server-driven spawning process for launching the FWD cli... - 04:58 PM Feature #4129 (Closed): map web client users to OS accounts
- 09:46 AM Bug #3691: literal $ character in format appears on the right side of the fill-in
- Both drivers work. Checker shows that results on 4gl in ChUI and GUI modes are identical. FWD results in ChUI and GUI...
Also available in: Atom