Skip to main content

UnifaceProject UNP-66 Runtime indication of entity widget type.

  • November 8, 2019
  • 8 replies
  • 0 views
Iain Sharp
Forum|alt.badge.img+5

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. 

Regards, 

Iain

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

Iain Sharp : Head of Technical Services, Jonas Metals Software

8 replies

Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • November 8, 2019

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. 

Regards, 

Iain

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

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


D
  • DanielIseliRocketeer
  • Rocketeer
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

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")
else
endif

Just an idea.

Daniel

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

Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


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 ....   🙂🙂

D
  • DanielIseliRocketeer
  • Rocketeer
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


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...

Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Author
  • Inspiring
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


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. 🙂 
  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. 


Iain

Iain Sharp : Head of Technical Services, Jonas Metals Software
Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Author
  • Inspiring
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


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). 

Iain Sharp : Head of Technical Services, Jonas Metals Software
Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


Hi Iain

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

Here are your wishes 🙂

$occisvisible

Description

Returns, if a occurence is (partly) visible

Syntax

$occisvisible(<entname>,<occnbr>)

$paintedoccnbr

Description

Returns or set the painted occ number for a occurence

Syntax

$painteroccnbr(<entname>,<occnbr>)

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

Example

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


$entityinfo

Description

Returns further information about the entity

Topic

  • „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

Syntax

$entityinfo(<entname>,<topic>)



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 😔


Ingo

Iain Sharp
Forum|alt.badge.img+5
  • Iain Sharp
  • Author
  • Inspiring
  • November 8, 2019

Hi Iain

There 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")
ELSE
ENDIF

Or in a component trigger:
IF("<MY_ENTITY_WIDGETTYPE>"=="EGRID")
ELSE
ENDIF


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.

Ingo


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

That one was cancelled. 😔

Iain Sharp : Head of Technical Services, Jonas Metals Software

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement