It would appear that if I am allowed to leave responses to comments on the wish list, the method of doing so escapes me. 

So, in response to the detectgrid sample linked by Daniel, I can see that the code may well have some use, however the particular usecase I have is during initialisation, not runtime, and is for all the painted fields in the entity, so using the windows handle for the field which has focus from the async trigger is WAY too late in the day. 

I want to control the display of columns in the grid based on a user's permissions. Looked up at initialisation of the screen. Or even in response to code in another field. Being able to get the status of the field I am already in does not help with either of these. 



P.S. why can't we comment on wishes? 

    CommentAdd your comment...

    1 answer


      Hi Iain

      There are two workarounds to do so, but not really best pratice (sad)
      First (at runtime)
       Deploy also the dictinary table UXGROUP in which WIDGETTYPE holds "EGRID" in case of a grid.

      Second (at compiletime)
      Programm a simple program which loops over UXGROUP.
      #define <$entname>_WIDGETTYPE=WIDGETTYPE.UXGROUP  in each components define trigger

      Now you can use code like (in a entity trigger:

      Or in a component trigger:

      First solution is straight forward but oyu have to deploy UXGROUP and retrieve at runtime
      For the second solution you have to remember to update the defines if you change the widgettype. But this solution is fast und you can also do some optimization at precompile time.


      1. Daniel Iseli

        Instead of using constants (workaround 2) you could also add the widget type to the more properties of an entity.

        In the entity trigger the code then could look like this:

        if ($entityproperties("<$entname>.<$modelname>", "WIDGETTYPE") == "WIDGETTYPE=EGRID")

        Just an idea.


        P.S. Don't know why you cannot add comments to a wish. Will ask around.

      2. Ingo Stiller

        Hi Daniel
        An with the next patch, UnifAce will do so at is own. There is no need for us to insert properties like this.
        Or ....   (smile)(smile)

      3. Daniel Iseli

        In an ideal world a lot should not be necessary. Unfortunately our world is not ideal...

        Vote for Iain's wish and this might reduce the need some day... (wink)

        I, however, think that it's quite a powerful feature to simply add additional properties to a field or entity. This can be handy in some situations. People that use build tools can even automate these kind of tasks when building the application. As Obama famously said: yes, we can...

        Have a nice weekend...

      4. Iain Sharp

        Yes, so what I had currently done (simultaneous with logging the wish in the first place) was to write the program Daniel suggested and add the MORE property ISGRID=T, which can be fetched from $entityproperties in the component. It means the user remembering to add the property, and/or a maintenance function to run the mass set against all grids run 'regularly' against the development environment. 

        Partially this was because I also wanted to remove the MORE property VISIBLE, as it was blowing up my conversion to V10.0.3 (which crashes when the hard coded entity properties are 'too big'. 

        So, as ususal with these things, if you put in the effort you can manually work around stuff like this, it's just a pain you can't find this class of information at runtime. 

        Stuff I'd like to see and (where applicable) control in grids. 

        1. First and last occurrences currently displayed in the window. (Faffing with $curocc is 60% effective)
        2. Whether it's a grid. (smile) 
        3. Which columns are displayed (where the grid is wider than the display area), made a little tricky by 'locked' columns, but basically the not-locked columns. This and 1. So I can write proc to reset the view after certain operations. 


      5. Iain Sharp

        Oooh, oooh, 

        4. A syntax setting in the field on the form which starts the $columnsyntax as HID (and the fieldsyntax as HID at the same time.) To hide 'calculation' columns (where extra info is stored). 

      6. Ingo Stiller

        Hi Iain

        I got a hole bunch of "nice to have" features written done in a document.

        Here are your wishes (smile)



        Returns, if a occurence is (partly) visible





        Returns or set the painted occ number for a occurence



        $painteroccnbr(<entname>,<occnbr>) = <paintedoccnbr>


        rearrange occurences, so that the 100th occurence in the hitlist to the third line on surface
        $painteroccnbr("a_ent",100) = 3



        Returns further information about the entity


        • „FIRST_PAINTED_OCC First occurence with a „painted occ number“
        • „LAST_PAINTED_OCC Last occurence with a „painted occ number“
        • „FIRST_VISIBLE_OCC“ First visible occurence (even partial)
        • „LAST_VISIBLE_OCC“ Last visible occurence (even partial)
        • „DIMENSION_X“ Count of painted occurences in X direction
        • „DIMENSION_Y“ Count of painted occurences in X direction



        On thuesday we did have the U.B.G. conference here in germany, I should have give the document to UnifAce (smile)

        On the other side, I believe, the wishlist is programmed as /dev/null (sad)


      7. Iain Sharp

        Well, there has been ONE, count 'em ONE wish which has changed status  from NEW to something else. 

        That one was cancelled. (sad)

      CommentAdd your comment...