Description



Use Case


I have a global proc that fills in auditing information into fields that exist in every database table upon write. I want to add another audit field into database tables but it will take some time to implement. If I had this new topic, I could check for the existence of this new field before trying to write to it.

Importance


not a need but a want

Type


Proc Code

Operating System


Windows

Status


Open

8 thoughts on “$entinfo($entname,\”FIELDLIST\”)”

  1. Status = Closed

    Although there may be other uses for the proposed syntax enhancement, the use case can easily be met using the $fieldname function.

    if ($fieldname(“AUDITDATE”) <> “”)

    AUDITDATE = $date

    endif

  2. My thoughts exactly Ulri! Actually, with all the other topics in $entinfo…..most of which I will never use…..the one I’m suggesting seems to be one of the most logical to include. I can think of loads of tools I could build with it to help manage my application. Hopefully, the Lab sees more of the big picture here so this wish can remain open….especially since it should be pretty easy to implement.

    1. A very clear statement which proofs that placing a wish is a wast of time. I recommend the dITo concept to add this functionality using some generated include procs. It’s easy, we can extend the functionality if we need, and we have it in a matter of days.

  3. I disagree with Uli, the sole use case we have been able to generate for this prospective code, is currently supported by a more specific test. <P>

    The original user wanted to know if a particular field existed within the current entity, and proposed to do this for checking for it’s existence within a returned list of all fields for the entity. <P>

    1. This specific function can be achieved using putlistitems/occ to get a list of all the fields, and testing for the fieldname. <P>

    2. The original poster’s requirement is better served by using the $fieldname function to test for the existence of the field in the entity. It saves several lines of code from the original idea. <P>

    Therefore I think this code is not currently required, unless there’s a use case where it IS the most effective method, which we, as users, have been unable to come up with. If I were running the development here, it would certainly be at the very bottom of the list, or written off as “User trained on correct methodology”.

    1. The putlistitems/occ circumvent only works if for this component the fieldlist is set to “all fields”. And if you are a purist, one uses a command which has not been implemented to deliver the required functionality. So you depend on side effects which is always smelling code. And using $fieldname instead: the helpfile documents this as: “check for the presence of a specified field in the component” which may not be identical to: field available in the datamodel. But as I stated earlier, there is a dITo concept how to bring reflection to uniface.

  4. I never intended this to actually generate this kind of scrutiny. It’s a wish, it’s got nothing to do with my training — I’m self-taught on this and very successful in my field. I’m merely asking for more functionality from a structure that already exists — simple in my mind. While I’m completely fine with Ulri’s approach, this is the wish list, yes? So, I state my wish — other developers vote on it — and let’s see where this ends up.  I don’t see the value in giving substitute suggestions or workarounds for a function that clearly doesn’t exist.  If the wish doesn’t move forward, no problem — I’ve done just fine without it.

Leave a Reply