Hi Thomas,

I hope I understand what your mean, not very sure though ... [I understand DRY as "Don't Repeat Yourself"]

>That was our take as well. While the introduced changes in the code were easy to understand, they were numerous ***and*** un-DRY, which ***is*** expected from a machine generated process.

do you mean that the same adaptation may occur at different places in the application? yes of course

>At latest at the point where some of the forms would have to be redesigned for small screened devices, additional code would follow - and then following the trails of machine assisted code droppings would lead to more maintainance due to introduced non-DRY-ness ;-))

redesigned for small screened devices: not necessarily - you have several options:

1/ you can save a .scx as a class from which you can derive several *.scx for each resolution; as each FiC request comes with browser's viewPortWidth and viewPortHeight as form properties, you can decide which form you'll send to your user:

thisForm.wForm(iCase(;
  between(thisForm.wViewPortWidth, w1, w2) and between(thisForm.wViewPortHeight, h1, h2),;
    'form1.scx',;
  between(thisForm.wViewPortWidth, w3, w4) and between(thisForm.wViewPortHeight, h3, h4),;
    'form2.scx',;
    'form3.scx';
), other parameters)

Notes:
- this solution will work exactly the same in desktop and web mode.
- all your code is in the parent form class - NO DRY

2/ you can keep a single source form and take advantage of CSS3 @display directive to adapt the layout to the client display (sample CSS distributed with FoxInCloud Application Server):

  @media screen  and (orientation: landscape) and (min-width:569px){ /* desktop = iPhone < 5 + 300 */
    
    #ecran_3_scx {width:780px; }

    #ecran_3_scx-myavatar_  {left:665px!important}
    #ecran_3_scx-democntbas {left:665px; }
    #ecran_3_scx-logoff {left:740px; }

    #ecran_3_scx-mycntgrdpage {width:770px; }
    #ecran_3_scx-mycntgrdpage-demolbllinespage {left:653px; }
    #ecran_3_scx-mycntgrdpage-mycbolinespage {left:704px; }
    #ecran_3_scx-mycntgrdpage-mynavq {left:645px; }
    #ecran_3_scx-mycntgrdpage .aw-grid-control {width:630px!important; }
  }

  @media screen  and (orientation: landscape) and (max-width:568px){ /* iPhone 5+ = iPhone < 5 + 88  */
    #ecran_3_scx {width:568px; }

    #ecran_3_scx-myavatar_  {left:453px!important}
    #ecran_3_scx-democntbas {left:453px; }
    #ecran_3_scx-logoff {left:518px; }

    #ecran_3_scx-mycntgrdpage {width:558px; }
    #ecran_3_scx-mycntgrdpage-demolbllinespage {left:441px; }
    #ecran_3_scx-mycntgrdpage-mycbolinespage {left:492px; }
    #ecran_3_scx-mycntgrdpage-mynavq {left:433px; }
    #ecran_3_scx-mycntgrdpage .aw-grid-control {width:420px!important; }
  }

  @media screen  and (orientation: landscape) and (max-width:480px){ /* iPhone < 5 */
    #ecran_3_scx {width:480px; }

    #ecran_3_scx-logoff {left:430px; }
    #ecran_3_scx-myavatar_  {left:365px!important}
    #ecran_3_scx-democntbas {left:365px; }

    #ecran_3_scx-mycntgrdpage {width:470px; }
    #ecran_3_scx-mycntgrdpage-demolbllinespage {left:353px; }
    #ecran_3_scx-mycntgrdpage-mycbolinespage {left:404px; }
    #ecran_3_scx-mycntgrdpage-mynavq {left:345px; }
    #ecran_3_scx-mycntgrdpage .aw-grid-control {width:333px!important; }
  }

Notes:
- you get the CSS selectors (eg '#ecran_3_scx-logoff {left:518px; }') by a simple copy-paste from the FiC-generated CSS - you just need to adjust the value (eg '518px;') to whatever you need
- You can even edit these values in the browser dev tools connected to your handheld device (eg Safari connected to an iPhone/iPad), visually adjust, copy and paste into your CSS file, reload the source CSS, etc.



> such an refactoring effort IMO should be added into cost calculation

We do agree ... that's why FAA estimates the time to complete adaptations




>I think there is more to Craigs point then you answer here - at least at the (long) time ago I looked at FIC.
>
>[reordered and put somewhat out of previous context ;-)) ]
>>It's intentionally simple, just meant to show how control/events are supported, and how code is adapted.
>
>That was our take as well. While the introduced changes in the code were easy to understand, they were numerous ***and*** un-DRY, which ***is*** expected from a machine generated process. At latest at the point where some of the forms would have to be redesigned for small screened devices, additional code would follow - and then following the trails of machine assisted code droppings would lead to more maintainance due to introduced non-DRY-ness ;-))
>
>The take here was more on the lines "we will cross that river more DRY than after code adaption" by refactoring the original code somewhat to eliminate most of the individual code droppings. But a few hints about already proven successful ways to minimize the added code would have been better. But such an refactoring effort IMO should be added into cost calculation - no fault of the original devs of the app (who could not foresee such an enhancement) or your machine assisted adaption (KISS principle is very good to follow there). Just normal biz, but should be seen and mentioned.
>
>my 0.001€
>
>thomas