Uniface on GitHub
Product (releases and patches)
Reported Issues (old)
Fixes and Updates
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?
Hi IainThere are two workarounds to do so, but not really best pratice 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.Insert #define <$entname>_WIDGETTYPE=WIDGETTYPE.UXGROUP in each components define trigger
Now you can use code like (in a entity trigger:IF("<<$entname>_WIDGETTYPE>"=="EGRID")ELSEENDIF
Or in a component trigger:IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")ELSEENDIF
First solution is straight forward but oyu have to deploy UXGROUP and retrieve at runtimeFor 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.Ingo
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")elseendif
Just an idea.
P.S. Don't know why you cannot add comments to a wish. Will ask around.
Hi DanielAn with the next patch, UnifAce will do so at is own. There is no need for us to insert properties like this.Or ....
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...
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...
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.
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).
Hi IainI got a hole bunch of "nice to have" features written done in a document.
Here are your wishes
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
On thuesday we did have the U.B.G. conference here in germany, I should have give the document to UnifAce
On the other side, I believe, the wishlist is programmed as /dev/null
Well, there has been ONE, count 'em ONE wish which has changed status from NEW to something else.
That one was cancelled.
© 2019 Uniface Privacy & Cookies | Privacy Statement | Legal