Pro's and Contra's fom Resources or Coded screens

[TimStone]

Carlos,

I actually have 3 dialogs for the large screens, and the user selects which one to use. This is a saved value, so it is only done once. So, for an Invoice dialog, there would be:

INVOICE ( 1024 x 768 )
INVOICEw ( Widescreen - 1920 x 1080 )
INVOICEl ( Tablet - designed for the 10.8 " Surface 3. Though it has a 1920 x 1280 resolution, that is too small to see, so controls are larger )

Any popup or lookup dialogs are 1024 x 768 and only the one is needed. Some capabilities are turned off on a tablet so there is no ....l option.

I know this seems like a lot of work, but it's only done one time, and adjustments are minor. The layouts are not responsive, but remember this is for screens that may have 30 or 40 controls on one dialog.

Marc,

As you can see above, there is one setting for each of 3 display options. I have not had a need for more than that. So ... if I modify an .rc, it automatically is picked up in the new build. All of my testing is done building within Visual Studio 2017, so that means about 15 to 20 seconds to update compiles, link, and display the new program. Releases use the MSFT libraries, but are built with a make file. I also do a build with xHarbour ( builder ). These are all a single keypress from within UE Studio ... so management is really fast and simple.

I don't know that an xbrowse would work out. I'd love to have dialogs be responsive/dynamic but I do have the challenge out there to do it with a heavily populated data screen and have it work well. If someone can show us @ command useage with 30 to 60 controls on a resizeable dialog, that handles it all well, then we certainly should explore a way to create using them ...

Tim

[Carlos Mora]

Otto

the problem I have is „modern“ look and different form factors.

Now I started working on responsive dialogs.
I don’t found a way to get such a design with available resource editors.

If you resize a dialog font should change and not only the size of the controls but also the controls should switch to the next row if necessary.

I use a similar concept as Antonio suggested above.

I think we should look into responsive web design an copy those concepts.

I'm working in web projects, and i feel more or less confortable doing responsive in html. Responsive, there is no doubt, is a good thing. But we don't feel forced to become "all the way" responsive in desktop apps, mostly because we write bussines programs, and noone will try to use such software in his/her 3" mobile phone screen.
Probably we can have the best of 2 worlds with simple ideas:
1) Design your form at it's minimun size. That will impose the minimun size of the form/dialog, It won't be resize to less than that size.
2) For each control, define its behavoir on resize:
2a) For top and bottom: Anchored to the top edge of its container, anchored to the bottom, move proportionally.
2b) For left and right: Anchored to the left edge, to the right edge, move proportionally.
3) At the init of the dialog, right after creating it, record the original controls position and size.
4) On dlg/win resize, change control's coordinates acodingly.
With that we get a very good solution. It is not responsive in the HTML sense, but it will behave a lot better in bussines apps.

As an example, in the following DIALOG :



https://prnt.sc/g4shyt

1 Controls anchored to the top left corner. their position doesnt change when dialog is resized, neither its size
2 Browse, top left corner anchored to the original position, bottom right corner moves with the forms corner
3 form buttons that move with the bottom right corner as form is resized.
In this example there is no proportional sizing, but is another posibility.
That's that way I see responsiveness applied to desktop forms.

Not limiting to word, a little bit of code.

Code: Select all  Expand view  RUN

/*
I've been working some time ago with the control resizing issue. After thinking a little bit about what behavoir would be wanted in every control, it can be resumed in 3 types:
1: No Change: the control's coordinates are hooked or anchored to the top/left window/dialog coordinates, so no change is made when windows is resized (e.g. left toolbar)
2: Proportional: used mostly with graphic controls, every control coordinate is changed proportionally to the dialog size.
3: Anchored: one ore more control's coordinates are hooked to the bottom/right edges, so control's size and/or position are changed acording to the new dialog size. This is the kind of behavoir Rick is looking for.

To achieve this, we need to know:
a) Window/Dialog and controls original sizes,
b) For every control, what behavoir is desired,
and then activate our new resizing strategy on windows/dlg resize, usually using bResize.

So immidiately the dialog is activated, we are going to pass throw every single child control to obtain it's starting position, and store it somewhere in the window.
Then store in every control wich will be it's behavoir at resizing time.


Sth interesting is that you can, in addition to control resize, set lower limits to windows resize so the dialog never gets under this values. Check :aMinMaxInfo var at windows class.

for controls there was used a RSZ attribute, encoding desired control behavoir.
the rest of info (original sizes, etc ) stored at CARGO instvar
*/

#define GW_CHILD      5
#define GW_HWNDNEXT   2

FUNCTION PreResize( oDlg )
   LOCAL hWnd:= oDlg:hWnd
   LOCAL aSize, aChildren, aSizeWnd
   LOCAL hCtrl

   IF !Empty( hWnd )
      aSizeWnd:= GetClientRect( hWnd )
      aSize:= GetWndRect( hWnd )
      aChildren:= {}

      hCtrl := GetWindow( hWnd, GW_CHILD )
      While hCtrl != 0
         aSize:= GetWndRect( hCtrl )
         aSize[3]-= aSize[1]
         aSize[4]-= aSize[2]
         ScreenToClient( hWnd, ASize )
         AAdd( aChildren, { hCtrl, aSize } )
         hCtrl = GetWindow( hCtrl, GW_HWNDNEXT )
      END

      // We need to store this somewhere, if you feel you have a better place please share it
      oDlg:Cargo:= { aSizeWnd, aChildren }

      // This could be another option... We can use this function to setup the min/Max info...
      oDlg:aMinMaxInfo = { GetSysMetrics(0), GetSysMetrics(1),;  // xMaxSize,      yMaxSize
                           0, 0 /*GetSysMetrics(0), GetSysMetrics(1) */  ,;  // xMaxPosition,  yMaxPosition
                           oDlg:nWidth, oDlg:nHeight,;  // xMinTrackSize, yMinTrackSize
                           GetSysMetrics(0), GetSysMetrics(1), ; // xMaxTrackSize, yMaxTrackSize
                           aSizeWnd, aChildren }

   ENDIF

RETURN NIL

FUNCTION DlgResizeCtrl( oDlg, nWidth, nHeight, nSizeType )
   LOCAL hWnd, oCtrl, nPos
   LOCAL aSize, aChildren, aSizeWnd, aCargo
   LOCAL hCtrl, aCtrl
   LOCAL nTop, nLeft, nOrigWidth, nOrigHeight, nBottom, nRight
   LOCAL nStyle, nKV, nKH // keep, Proporcional, bound to bottom,

   IF ValType(oDlg:Cargo) == 'A'
      nTop:=  oDlg:Cargo[1][1]
      nLeft:= oDlg:Cargo[1][2]
      nOrigHeight := oDlg:Cargo[1][3] - nTop
      nOrigWidth  := oDlg:Cargo[1][4] - nLeft
      aSizeWnd:= GetClientRect( oDlg:hWnd )

      nHeight:= aSizeWnd[3]
      nWidth := aSizeWnd[4]
      nKH:= nWidth / nOrigWidth
      nKV:= nHeight / nOrigHeight
      nDH:= nWidth - nOrigWidth
      nDV:= nHeight - nOrigHeight

      aChildren:= oDlg:Cargo[2]

      FOR EACH aCtrl IN aChildren
         IF ( nPos:= GetProp( aCtrl[1], "RSZ" ) ) != 0
            nStyle:= nPos % 256
            nPos:= Int( nPos / 256 )
            nTop    := (nPos % 16) >= 8
            nLeft   := (nPos % 8) >= 4
            nBottom := (nPos % 4) >= 2
            nRight  := (nPos % 2) == 1

            Do Case
            Case nStyle == 0 // keep, do nothing
               //  SetWindowPos( aCtrl[1], 0, aCtrl[2][1], aCtrl[2][2], aCtrl[2][4], aCtrl[2][3], 4 )
            Case nStyle == 1 // Proportional
               SetWindowPos( aCtrl[1], 0, Int( aCtrl[2][1] * nKV ), Int( aCtrl[2][2] * nKH ), Int( aCtrl[2][4] * nKH ), Int( aCtrl[2][3] * nKV ), 4 )
            Case nStyle == 2 // Anchors
               SetWindowPos( aCtrl[1], 0, ;
                  If( nTop,     aCtrl[2][1]+nDV, aCtrl[2][1] ), ;
                  If( nLeft,    aCtrl[2][2]+nDH, aCtrl[2][2] ), ;
                  If( nRight,   aCtrl[2][4]+nDH, aCtrl[2][4] ), ;
                  If( nBottom,  aCtrl[2][3]+nDV, aCtrl[2][3] ), ;
                  4 )
            EndCase

         ENDIF
      EndFor
      oDlg:Refresh()
   ENDIF
RETURN NIL


 

To be used in code sth like:

Code: Select all  Expand view  RUN

   oDlg:bResized := {|nSizeType, nWidth, nHeight| DlgResizeCtrl( oDlg, nWidth, nHeight, nSizeType ) }

   ACTIVATE DIALOG oDlg CENTERED ;
         ON INIT ( PreResize( oDlg ), SetProp( oBrowse:hWnd, 'RSZ', 0x302 ), SetProp( oBtn1:hWnd, 'RSZ', 0xf02 ), SetProp( oBtn2:hWnd, 'RSZ', 0xf02 ), SetProp( oBtn3:hWnd, 'RSZ', 0xf02 ) )

 

It may look a little bit cryptic but it could be a good starting point

[Gale FORd]

have you guys looked at Easydialog yet? i looked at it a number of ears ago and it helped with controls on resized dialogs.

[D.Fernandez]

Hi, A long time ago, I bought EasyPreview from Tim. I have a demo of EasyDialog.
Look Great in the example. Each user can have hin own defined dialog sizes.
May be someone can contact Tim to ask him from EasyDialog.

Best regards.

Ruben Dario Fernandez

[Gale FORd]

i think it was included with the deal for EasyReport.
http://forums.fivetechsupport.com/viewtopic.php?f=30&t=29057

[Silvio.Falconi]

For dialogs from resources there is a good class for resize the dialog and run ok - search on this forum japan or cina user

For the sources dialogs I use a function of Frank Demont make me many years ago : also this function is on this forum it resize all controls and resize also fonts

Fwh need a dialog designer to draw ouur dialog easy with no longer time

[Gale FORd]

Just downloaded Easydialog and sample. Looks like we did not get all of the files. Interesting approach and i wish we had all of the files.

[Gale FORd]

Found a location to download trial version that had all of the example information. It is worth checking out the example.
Resizing dialog looks really nice. Don't forget to try out design mode found under system menu.

http://www.reportdesigner.info/downloads/EasyDialog.exe

[Silvio.Falconi]

With ED you must create before the dialog ....
I wish an utility to create a dialog from init

[Gale FORd]

Creating screens is important and it would be great to have withing program.
It would also be handy to be able to handle changes to the position and size of controls in the dialog after it is created.

[MGA]

http://www.reportdesigner.info/

[dpesic]

We use 'Coded screens' in our IDE. Every identity (dialog, menus, reports, scripts, data view) in app is described via metadata, stored in database and it can be executed in every OS (Windows app, Linux terminal, Windows terminal) and at the end of this year HTML app.

Here is some video about our IDE ...

http://89.216.28.77:90/rws_demo.mp4

[Otto]

Hello,
thank you for shareing.
Where do we see how you adress the controls which are stored in your database through sourcecode.
Best regards,
Otto

[dpesic]

As you can see in this video (01:08), coordinates for this TGet object is (3,2) in virtual rows also it depends on default font size in app.

Name of this object is 'm_sifra' and its created with __ObjAddData method of TDialog class. Complete reference is: _self:m_sifra:cText for example. Its created in runtime.


p.s. Sorry for my bad english

[Silvio.Falconi]

But....Antonio, Cristobal....
why not found a solution for this utility ? ( on .\samples folder

design.prg

when we compile the prg out it not show the dialog we created