emptyblock rule
Hi,
Prolint returns an error with blocks such as enable_UI and disable_UI eg...
PROCEDURE enable_UI :
/*------------------------------------------------------------------------------
Purpose: ENABLE the User Interface
Parameters:
Notes: Here we display/view/enable the widgets in the
user-interface. In addition, OPEN all queries
associated with each FRAME and BROWSE.
These statements here are based on the "Other
Settings" section of the widget Property Sheets.
------------------------------------------------------------------------------*/
{&OPEN-BROWSERS-IN-QUERY-fMain}
END PROCEDURE.
Also,
PROCEDURE disable_UI :
/*------------------------------------------------------------------------------
Purpose: DISABLE the User Interface
Parameters:
Notes: Here we clean-up the user-interface by deleting
dynamic widgets we have created and/or hide
frames. This procedure is usually called when
we are ready to "clean-up" after running.
------------------------------------------------------------------------------*/
/* Hide all frames. */
HIDE FRAME fMain.
IF THIS-PROCEDURE:PERSISTENT THEN DELETE PROCEDURE THIS-PROCEDURE.
END PROCEDURE.
Any thoughts on this?
Thanks,
Matt
- Login to post comments
re: emptyblock rule
Hi Matt,
Are you sure that rule emptyblock complaints about procedure disable_ui? That would simply be a bug, because the procedure is not empty at all. Can you please confirm that?
Procedure enable_ui is actually empty when {&OPEN-BROWSERS-IN-QUERY-fMain} resolves to nothing. The rule would (in that case) be right when it says that enable_ui is an empty block, but I understand you'd still want to suppress the warning because enable_ui is created by Appbuilder.
There are ways to achieve this....
1. see this line in file prolint/rules/rules.d :
"emptyblock" 5 yes no no no no "Locates empty code blocks" "Style"
the last "no" here means "no do not try to ignore AB-generated code". If it is changed to yes, then Prolint should try to ignore procedure enable_ui, just like any other block that is marked with "&ANALYZE-SUSPEND _UIB-CODE-BLOCK"
2. the code of rule emptyblock (in prolint/rules/emptyblock.p) could be changed to always ignore procedure enable_UI even if the IgnoreAB setting is "no", is we can assume that people won't manually write a procedure with that name.
I guess (1), change rules.d, is the best choice. Do you agree? Would you please give this a try and let me know if this returns the results you want? Because then I can change the standard rules.d.
re:empyblock rule
Hi Jurjen,
Sorry, my mistake. It's just enable_ui that's the problem. I've changed rules.d to show "emptyblock" yes no no no yes but the file I am checking still gives me an error because enable_ui is an empty block. By changing the last no to yes would that ignore all blocks marked with "&ANALYZE-SUSPEND _UIB-CODE-BLOCK"? Wouldn't that ignore all procedures? Should we be looking at amending emptyblock.p to ignore procedure "enable_UI". It would be safe to assume that no one would create a procedure of this name.
Thanks,
Matt
re: emptyblock rule
Hi Matt,
You are right, I got it all backwards. When the IgnoreAB flag is set to yes, the rule will try to ignore everythng that is NOT in a "&ANALYZE-SUSPEND _UIB-CODE-BLOCK" block. eg, it will inspect internal procedures and functions, but will ignore most of the stuff between them.
Ok I suppose a hack in emptyblock.p to make an exception for procedure "enable_UI" seems fine to me.
re: emptyblock rule
Just a thought....
enable_UI and disable_UI should NOT be ignored if the &ANALYZE-SUSPEND line does not contain the string _DEFAULT-ENABLE or _DEFAULT-DISABLE. The lack of those keywords indicates that the block is editable by the developer, and it should still be checked.
And yes, people do edit it. I have 3 examples sitting on my desk for me to put into a Lunch and Learn training presentation to tell our developers to stop.
that's a good addition,
that's a good addition, thanks Glen