During compiling a form some extra warnings appear. Some of them are not really that important for developers. For example: - 1074 ent missing - 1076 no path - 6921 used for ref. int. When more warnings are generated it becomes more difficult to see the important ones instantly. Developers should have the possibility to enable/disable certain warnings in the Compiler Preferences.

Use Case

Especially when bulk-compiling unimportant warnings are distracting, so a compile with only summary info and real errors/warnings (for example unknown fields) would be very appreciated.




Uniface Development Environment

Operating System

Not Applicable



6 thoughts on “Ability to enable/disable certain compiler warnings”

      1. Yeah, see my comment below. 1234 related entity warnings, four page downs on the message frame all of them relating to up entities with no-updates set and no code in any of write,delete,write up or delete up trigger…………………………………… makes finding ACTUAL problems somewhat hit and miss.

  1. Also, I actually think these warnings have relevance sometimes, so it’s more that I want to be able to note that I have seen and decided a PARTICULAR no path to ent on a particular component is a planned thing, and prevent it showing again. I need to see it until I’ve said I don’t want to. I don’t want to turn off the entire warning for every ent on every component.

    1. that’s what you have in some other languages where you can apply the @overwrite annotation to state that this was intentional and not because you just used the same entry names twice.


      With entries, this is not so hard, but what is the single best place to have a “no-path-found” annotation? By logic, it should be part of the FORMPIC or UXGROUP.

      1. ‘For me’ it’s a case of having the current message frame contents in an ‘editable’ form where each warning message has the ability to be tagged as considered and ignored, and doesn’t come back until situations change.

        This might be some form of automatic #define in some trigger somewhere (which would allow pre-emptive switching off of the issues) or an entirely new entity in DICT, or the cross reference table, or something.

        I’ve been setting some tables up with component subtypes etc, and some of my services now have over 1000 warning messages, all but one of which are previously considered and ignored. Finding the nugget of useful information in the morass of excess is now a skilled job….

Leave a Reply