How to determine designtime in a BusinessEntity Cancel The title field is required!

1. Carl Verbiest

   

   67 posts
   Registered:
   12 Oct 2018
   01 Mar 2021

   Link to this post

   For a UI component we can use a designtime property to determine we are designing the component.
   
   this-object:DesignTime = Progress.Util.EnumHelper:AreEqual(System.ComponentModel.LicenseManager:UsageMode,
               System.ComponentModel.LicenseUsageMode:Designtime) .
   
   Is there an equivalent check we could use to determine a BE is run from the BE designer e.g. to generate a viewer ?
   
   Consultingwerk.Framework.FrameworkSettings:BaseRegistryKey = "Software~\Consultingwerk Ltd.~\Business Entity Designer~\":U
   
   Seems to be a candidate
   
2. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   Answered

   01 Mar 2021 in reply to Carl Verbiest

   Link to this post

   There isn't a reliable way. But what would it be needed for? 
   
   A Business Entity should not be doing relevant stutt in the constructor - as that would be creating state and that conflicts with the concept of the Business Entity as a stateless service component.
   
   And the UI components should only call into the Business Entity for FetchDataset (empty dataset with schema).
   
   So what's the real problem? 
3. Carl Verbiest

   

   67 posts
   Registered:
   12 Oct 2018
   Answered

   01 Mar 2021 in reply to Mike Fechner

   Link to this post

   Love your answer ;-)
   
   The real problem of course is in the word "should", as long as this does not state "MUST NOT" there will be code violating this.
   In this case it was getting license info that has an impact on the BE, pretty harmless but it is state
   
4. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   01 Mar 2021 in reply to Mike Fechner

   Link to this post

   You can always introduce your own static properties and assign them from the JSON startup file depending on the session tyle.
5. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   01 Mar 2021 in reply to Mike Fechner

   Link to this post

   Well ....
   
   "The real problem of course is in the word "should", as long as this does not state "MUST NOT" there will be code violating this."
   
   You're the master of your team's coding guide line and enforcement