Results 1 to 6 of 6

Thread: New UI state machine in RC4

  1. #1
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,161
    Blog Entries
    22

    New UI state machine in RC4

    As many of you know Lianja is heavily architected around the concept of ART (Actions, Rules and Transitions) and I have been exposing more and more of this functionality gradually during each beta release (browse through the roadmap and see).

    In RC4 in response to a lot of developer requests I have now completely opened this up.

    When building UIs you quite often want the UI to adjust itself to the data being presented or the data being input interactively by end users.

    The whole of the UI in a Lianja App is now a "UI State Machine" controlled by Actions (The ART architecture).

    Each page, section, fields within sections and columns within grids can have one or more UI states (the "UI States" attribute in the attributes dialog). These are simple comma separated lists. e.g. input_data,input_invoice,mandatory

    You control the states using a simple but effective mechanism which can be triggered in any of the delegates or specified on hyperlinks in a section footer.

    Lets take a look at way we change the state of the UI without having to jump through hoops.

    Code:
    Lianja.showDocument("changestate:not_invoice?visible=false")
    This would cause the ART engine to traverse all pages, sections and fields in the whole App and hide all visual elements that have "not_invoice" specified in their state list.

    Properties can be applied to specific pages and/or sections and grouped together like this:

    Code:
    Lianja.showDocument("page:page1.section1?action=changestate?state=mandatory&backcolor=beige&border=red")
    When declaring delegates in your App you can prefix the delegate with a "!" to specify an "inline" command e.g.

    Code:
    !Lianja.showDocument("page:page1.section1?action=changestate?state=mandatory&backcolor=beige&border=red")
    Note also that you can use a query-style syntax as your delegate:

    Code:
    $("page:page1.section1?action=changestate?state=mandatory&backcolor=beige&border=red")
    You should also consider just using CSS styles that are applied to the UI controls on a state change.

    Code:
    !Lianja.showDocument("page:page1.section1?action=changestate?state=mandatory&stylesheet=app:/mandatory.css")
    Hope you enjoy this new functionality which will work across all UIs; desktop, web and mobile and hopefully save you a lot of coding.

    Note that state changes and other UI presentation rules are only applied when the App is in runtime mode from the Lianja App Center so as not to affect the basic design of the App in development mode.
    Last edited by yvonne.milne; 2013-03-21 at 12:26.
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  2. #2
    Junior Member
    Join Date
    Feb 2012
    Posts
    19
    This looks very promising.
    Awaiting rc4...

  3. #3

    Programmatically toggle fullscreen

    hi,

    Can I use this UI State to automatically click the Fullscreen toggle button programmatically? Either by command or by using UI State?
    Name:  Fullscreen.png
Views: 196
Size:  14.0 KB

    Thanks & Regards,
    Murali

  4. #4
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,161
    Blog Entries
    22
    As of v1.0.1 this is a property on the Lianja system object.

    Code:
    Lianja.fullscreen = 1
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  5. #5
    cool!...thanks Barry.

    Cheers,
    Murali

  6. #6
    Senior Member
    Join Date
    Jan 2014
    Posts
    369
    Hi Barry

    We are now using the UI State machine to conditionally control other parts of a section (field visibility) & it works really well.

    However, when using a checkbox to control the visibility of other fields, there seems to be a timing issue - we seem to have missed something.

    For example if .T. in a checkbox means other fields visible and .F. means they are not visible, the UI state mechanism works great when the record pointer is moved but not when the checkbox value is changed interactively with a mouse and before the checkbox loses focus. In VFP we would have used the Valid method of the checkbox.

    We can get round this by having a prg that takes the value of the checkbox as a parameter - in the InteractiveChange method of the checkbox we call our function
    UIStatesController(this.value) which works great. Interactive change is clearly no good for text fields though.

    Is there a more elegant way to do this which respects both the table data when moving between records and interactive changes made by the user?

    Hope that was clear

    Thanks in advance

    SpringBox

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Journey into the Cloud
Join us