Several properties generated by the AppBuilder in the CREATE WINDOW statement (&ANALYZE-SUSPEND _CREATE-WINDOW section), are generated as "yes" or "no", in lower case.
This causes warnings "Keywords are in lower case." in the workspace.
Hi Simon,
There is an issue logged for this:PSC00258856. Issue is closed as code generation is quite complex and this would require changes to a lot of code.
Thanks,
Swathi.
The AppBuilder has a property screen with tick boxes, saved in some sort of field or variable.
The code generator check each of these tick boxes and generate "YES" or "NO" is for some and "yes" or "no" for others.
It is a matter of finding the location in the code where the "CREATE WINDOW" statement is generated and fixing the case of the strings written to the source for the those properties written in lower case.
I've been involved in generating code the past 18 years and this type of change is not complex at all. On the contrary, it is very easy. Properly written, our code generaters emitted similar code in similar places ever since t heir birth in v. 6, I doubt that the code base of a successful company like PCS will be any different.
The AppBuilder has a property screen with tick boxes, saved in some sort of field or variable.
The code generator check each of these tick boxes and generate "YES" or "NO" is for some and "yes" or "no" for others.
It is a matter of finding the location in the code where the "CREATE WINDOW" statement is generated and fixing the case of the strings written to the source for the those properties written in lower case.
I've been involved in generating code the past 18 years and this type of change is not complex at all. On the contrary, it is very easy. Properly written, our code generaters emitted similar code in similar places ever since t heir birth in v. 6, I doubt that the code base of a successful company like PCS will be any different.
Flag this post as spam/abuse.
PSC00258856 was a request to make the AppBuilder generate code according to PDS upper or lower casing preference and was closed as no plan to fix.
There is also issue PSC00193565 - Casing issue warning should not come up for auto generated files. This is currently scheduled for 11.5. The proper fix for this is to ensure that the “case warnings parser” ignores the generated code sections. The casing of these variables do not matter whatsoever and we want to allow users to use lower case in editable code without getting warnings from generated code. This is currently an internal bug, so getting customer input (complains) may help get it prioritized.
If you want to get the specific windows yes and no values generated consistently in upper case you should probably enter a specific bug for that. You can provide code to Support as a proposed solution to any bug or enhancement. Note that PDS may generate this code internally each time you switch between text editor and design, so a fix that only addresses the inconsistent casing must not add any overhead.
The proper fix for this is to ensure that the “case warnings parser” ignores the generated code sections.
I would disagree. I would think the proper fix was to generate the code in the proper case. Not only is it a better solution, but it should be easier.
For once, I agree with TMH.
On Tue, Jul 22, 2014 at 1:24 PM, Thomas Mercer-Hursh
wrote:
> RE: AppBuilder generated code causes warnings
> Reply by Thomas Mercer-Hursh
>
> The proper fix for this is to ensure that the “case warnings parser” ignores
> the generated code sections.
>
> I would disagree. I would think the proper fix was to generate the code in
> the proper case. Not only is it a better solution, but it should be easier.
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Tim Kuehn: Senior Consultant - TDK Consulting Services
Ontario PUG President
PUG Challenge Americas Executive, Program Committee Chair
Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
The proper fix for this is to ensure that the “case warnings parser” ignores the generated code sections.
I would disagree. I would think the proper fix was to generate the code in the proper case. Not only is it a better solution, but it should be easier.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
I wasn't referring to *all* new code. And, I recognize that fixing the case on save will eliminate a lot of this kind of thing. That is what I rely on to get stuff vaguely how I like it. Applying formatting universally would scare me since I and PDSOE don't always agree on formatting. It just seems simple enough to observe the current flag or, if necessary, provide a one time setup which affected all future code produced from that install.
Flag this post as spam/abuse.
The proper fix for this is to ensure that the “case warnings parser” ignores the generated code sections.
I would disagree. I would think the proper fix was to generate the code in the proper case. Not only is it a better solution, but it should be easier.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
The proper fix for this is to ensure that the “case warnings parser” ignores the generated code sections.
I would disagree. I would think the proper fix was to generate the code in the proper case. Not only is it a better solution, but it should be easier.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
You're assuming one is doing global edits in order to avoid a compiler warning.
I'm assuming the appbuilder will be changed to generate compiler-friendly code when it's used to update a particular program - ie it'll generate new code in a compiler friendly way, and old code won't be changed unless a shop wants to go in and change it.
Another option a shop could do is re-generate the code to compiler friendly standards, check that change in, then make the required functionality changes afterwards.
If all an "updated appbuilder" is doing is generating the same code with different casing, would a case change be caught and recorded as a diff by most SCMS systems?
Right, Tim ... if a shop does something like change standards from upper to lower, it isn't just going to be the generated AppBuilder code that causes excitement with case differences, especially if something like casing on save is used to apply uniform standards. If one has that kind of transition, clearly the best thing to do would be to check out the whole code base, apply the change, and then check it back. If people elect to do it one program at a time, it is still better to take each new program, apply the standard, check it in as a baseline with the appropriate comment, and then proceed with any functional changes. Frankly, I think a shop changing standards is going to be pretty rare.
And, Peter, if a shop did lower case everything and check it in as a new baseline, then along comes AppBuilder and puts out new code with upper case in it, creating a false difference.
This discussion is starting to move nowhere…. As it’s mixing philosophical thoughts, a bug in the tool and an enhancement request.
Let’s face the fact: The AppBuilder has eversince generated code following the documentation standard – upper case. With a few exceptions, like the values to logical attributes of the CREATE WINDOW statement. Even though for 20 years nobody cared about this it now becomes annoying because now we have a tool with case warnings. But this is a bug and it should not be hard to fix this!
The other thing about the AppBuilder generating all lower case or all upper case or the case warnings parser to ignore the generate code are enhancement requests. I see that they might take longer to implement and may not be in the focus of the next OE releases.
Honestly, I am not too keen on seeing any of the two latter options implemented. Most teams that I know that use the AppBuilder either have no coding standard at all and would turn off the case warnings or follow the documentation standard and would benefit from the original issue being fixed.
The AppBuilder is notorious for swopping lots of stuff around, especially if the program was last updated with a different version.
On the other hand, most diff tools have options to ignore case changes.
[quote user="Peter Judge"]
[/quote]