FiveTech Support Forums

karinha wrote:Perfect Jimmy, but even so, I would never use this model. It doesn't make sense in a SIMPLE FOLDEREX.

Silvio wrote:or do all the dialogs in the folder have to be the same size?

I think the same as you Jimmy. The problem is that I work in a commercial company and the CUSTOMER is in charge. In this example, the customer ordered "ONLY" 20 FOLDERs. He pays a fortune, and I have to do it, you know?

Pienso lo mismo que tú Jimmy. El problema es que trabajo en una empresa comercial y el CLIENTE está a cargo. En este ejemplo, el cliente pidió "SÓLO" 20 FOLDERs. Él paga una fortuna y yo tengo que hacerlo, ¿sabes?

Regards, saludos.

Jimmy wrote:hi,

Perfect Jimmy, but even so, I would never use this model. It doesn't make sense in a SIMPLE FOLDEREX.

perhaps i do not understand what you and Silvio try to do.

Silvio wrote:or do all the dialogs in the folder have to be the same size?

i prefer not to change size or other Style within a Dialog

i would never use so much FolderEX like in your Sample or 2-line TAB, for me it is "too much" in a Dialog.
i like to use Simple Design Style and CODE which is easy to read and understand

karinha wrote:I think the same as you Jimmy. The problem is that I work in a commercial company and the CUSTOMER is in charge. In this example, the customer ordered "ONLY" 20 FOLDERs. He pays a fortune, and I have to do it, you know?

Pienso lo mismo que tú Jimmy. El problema es que trabajo en una empresa comercial y el CLIENTE está a cargo. En este ejemplo, el cliente pidió "SÓLO" 20 FOLDERs. Él paga una fortuna y yo tengo que hacerlo, ¿sabes?

Regards, saludos.

#include "FiveWin.ch"
#include "Constant.ch"

#define DEF_COLOR1 nRgb( 245,244,234)
 #define DEF_COLOR2 nRgb(233,229,206)
 #define DEF_COLOR3  RGB( 238,236,219 )
 #define DEF_COLOR4  nRgb(218,214,179)

 #define DLG_nColorDlg     RGB(245,245,235)
 #define DLG_nColortitle1  RGB(219,230,244)
 #define DLG_nColortitle2  RGB(207,221,239)
 #define DLG_nColorBar1    RGB(250,250,245)
 #define DLG_nColorBar2    RGB(245,245,235)
 #define DLG_nColorBtn1    RGB(245,245,235)
 #define DLG_nColorBtn2    RGB(250,250,245)
 #define DLG_nColorBtnB    RGB(195,195,185)





Function Test()
local oDlg,oFld,oFont,oBold
local oBar,oBtnAnnulla,oBtnAiuto,oBtnConferma
local aFolder := {"Menu1","Menu2","Menu3","Menu4","Menu5","Menu6"}
local aCooDlg := {0,0}

// per la dialog e folder
local nHeight:= 680

local aPt := { 111,200 }


          local nBottom:= 41
          local nRight := 94.6
          local nHt       := nBottom * DLG_CHARPIX_H
          local nWd       := Max( nRight * DLG_CHARPIX_W, 180 )

        aCooDlg[1]:=nWd
        aCooDlg[2]:=nHt


        oFont := TFont():New( "TAHOMA", 0, 18,, )
        oBold := TFont():New( "TAHOMA", 0, 14,,.t. )


       DEFINE DIALOG oDlg SIZE  870,nHeight PIXEL TRUEPIXEL;
       FONT oFont  title "test folder" COLOR CLR_BLACK, DLG_nColorDlg  ;
       STYLE nOR( DS_MODALFRAME, WS_POPUP, WS_CAPTION, WS_SYSMENU, ;
                  WS_MINIMIZEBOX)

       aPt   := ClientToScreen( oDlg:hWnd, aPt )
      //-------------------------------------------------ButtonBar
      DEFINE BUTTONBAR oBar OF oDlg SIZE 84, 70  2015   BOTTOM NOBORDER
      DEFINE BUTTON oBtnAnnulla OF oBar ;
      FILENAME "DLG_NO";
      PROMPT "Annulla" TOOLTIP "Esci" ;
      ACTION   ( oDlg:end( IDCANCEL ) )
      DEFINE BUTTON oBtnAiuto OF oBar  ;
      FILENAME "HLP_DLG";
      PROMPT "Aiuto" TOOLTIP "Aiuto" ;
      ACTION NIL   GROUP
      DEFINE BUTTON oBtnConferma OF oBar  BTNRIGHT  ;
      FILENAME "DLG_OK";
      PROMPT "Conferma" ;
      TOOLTIP "Conferma i dati" ;
      ACTION   ( oDlg:end( IDOK ) )
      oBar:bClrGrad := { | lPressed | If( ! lPressed,;
                 { { 1, DLG_nColorBar1, DLG_nColorBar1} },;
                 { { 1, DLG_nColorBar2, DLG_nColorBar2} } ) }
     //-----------------------------------------------------------------//







   @100,0 FOLDEREX oFolder PROMPTS aFolder ;
   SIZE oDlg:nWidth,oDlg:nHeight-oBar:nheight  PIXEL   ;
   FONT oFont  ;
   COLOR nRgb( 245,244,234) ROUND 0


   oFolder:bAction := { || IF(oFolder:nOption=3 .or. oFolder:nOption=6 ,;
                         (oDlg:nHeight:=400,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )),;
                         (oDlg:nHeight:=680,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )) ) }


            oDlg:bResized  := <||
              local oRect    := oDlg:GetCliRect()
              oFolder:nTop := oRect:ntop+120
              oFolder:nHeight := oRect:nbottom-190
              oFolder:nWidth  := oRect:nWidth
              oBar:GoDown()
              oBar:refresh()
              return nil
             >

ACTIVATE DIALOG oDlg CENTERED ;
   ON INIT ( oDlg:Move( aPt[ 1 ] , aPt[ 2 ] ),;
                Eval(  oDlg:bResized),;
                ChangeButtons(oBar ),;
                oBar:refresh(),;
                Eval(oFolder:baction) )


//------------------------------------------------------------------------//
function ChangeButtons( oBar )
       AEval( oBar:aControls, { | oCtrl | oCtrl:nTop += 4, oCtrl:nHeight -= 4 } )
 return .T.
//----------------------------------------------//

Hello Silvio,

you posted a very good example. Respect.

Best regards,

Otto

Silvio.Falconi wrote: RESOLVED ???
NO

 oFolder:bAction := { || IF(oFolder:nOption=3 .or. oFolder:nOption=6 ,;
                           (oDlg:nHeight:=400,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )),;
                           (oDlg:nHeight:=680,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )) ) }

Jimmy wrote:hi Silvio,

RESOLVED ???
NO

why do you use different Size for FolderEX Body of MENU 3 and MENU 6 ?

Code (fw): Select all Collapse

 oFolder:bAction := { || IF(oFolder:nOption=3 .or. oFolder:nOption=6 ,;
                           (oDlg:nHeight:=400,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )),;
                           (oDlg:nHeight:=680,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )) ) }

for me it seems a bad Design to change SIze

Buttonbar will change Position so User need to move Mouse to new Position to press a Button.
why not use fix Size and Position to avoid losing Focus and moving Mouse.

Jimmy wrote:hi Silvio,

RESOLVED ???
NO

why do you use different Size for FolderEX Body of MENU 3 and MENU 6 ?

Code (fw): Select all Collapse

 oFolder:bAction := { || IF(oFolder:nOption=3 .or. oFolder:nOption=6 ,;
                           (oDlg:nHeight:=400,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )),;
                           (oDlg:nHeight:=680,oDlg:Move( aPt[ 1 ] , aPt[ 2 ] )) ) }

for me it seems a bad Design to change SIze

Buttonbar will change Position so User need to move Mouse to new Position to press a Button.
why not use fix Size and Position to avoid losing Focus and moving Mouse.

Silvio, I am an ETERNAL LEARNER. Jimmy, you are BIG! Congratulations. Unlike you Silvio, I'm not ARROGANT! All knowledge for me is little!

Silvio, soy un ETERNO APRENDIZ. Jimmy, ¡eres GRANDE! Felicidades. ¡A diferencia de ti Silvio, yo no soy ARROGANTE! ¡Todo conocimiento para mí es poco!

Regards, saludos.

Silvio wrote:Because on 3 and 6 Tab i have many controls on 6 or few controls on 3

Hello friends,

I’ve consulted AI to gather insights, which are based on the collective opinions of numerous individuals.

Best regards,

Otto

Objective Recommendation for Dynamic Height Adjustment in New Development

Modern Aesthetics:

Dynamic height adjustment aligns with modern design principles, providing a sleek, adaptive, and user-friendly interface. This approach demonstrates that the application is responsive to content and user interaction, offering a more engaging experience.

User Experience:

Users benefit from a layout that adjusts to the content they are viewing. This reduces unnecessary scrolling and presents information in a cleaner, more organized manner. It can enhance the perceived sophistication of the application.

Implementation Considerations:

Smooth Transitions: Ensure smooth transitions between tabs to mitigate any flicker effect. Using CSS animations or JavaScript libraries can help create seamless transitions that enhance the overall user experience.

Performance: While dynamic height adjustment can be more resource-intensive, optimizing the code and using efficient programming practices can minimize performance impacts. Preloading content and using lazy loading strategies can also help maintain performance.

Fallbacks: Consider providing fallbacks for older devices or browsers that may not handle dynamic adjustments well. This ensures a wider audience can still have a good experience, even if it’s not the full dynamic experience.

Visual Consistency:

Minimize Empty Space: Set a minimum height for tabs to avoid excessive white space when switching to tabs with less content. This maintains a visually balanced interface.

Responsive Design: Ensure the layout is fully responsive, adapting not only to the content but also to different screen sizes and orientations. This is crucial for maintaining usability across various devices.

Best Practices:

User Testing: Conduct thorough user testing to gather feedback on the dynamic height adjustment. This helps identify any potential issues and ensures the feature meets user needs effectively.

Accessibility: Ensure that dynamic height adjustments do not negatively impact accessibility. Screen readers and other assistive technologies should still provide a smooth experience for users with disabilities.

Conclusion

For a new development, embracing dynamic height adjustment is recommended to achieve a modern and flexible design. By carefully considering implementation details, performance optimization, and

user feedback, you can create an application that is both visually appealing and highly functional. This approach aligns with contemporary design trends and user expectations, making your application stand out in a competitive market.

hi Otto,

the answers of an AI depend on the question

> I’ve consulted AI to gather insights, which are based on the collective opinions of numerous individuals.

which programming language do those people work with ? we talk about Win32 Apps

assuming you needed 10 buttons: would you choose different heights for them?

would you mix single-line and multi-line buttons?

>This reduces unnecessary scrolling

the KI ​​assumes large quantities, which is not the case here

everything that should be displayed "fits" into on one TAB page

>Smooth Transitions: Ensure smooth transitions between tabs to mitigate any flicker effect.

we are not talking about Internet Techniques (CSS & JavasSript), which are not available in win32

so your Question was Wrong to ask a KI, as i don't think you can ask an KI about people's taste

karinha wrote:hahaha, Silvio, you're not boring. If it works for you, use it. If it doesn't work for you, don't use it. your model does not work. Mine works. Although, I don't see any use in this FOLDEREX model that you created. Crazy thing like you. Have a good day.

jajaja, Silvio, no eres aburrido. Si te funciona, úsalo. Si no te funciona, no lo uses. tu modelo no funciona. El mío funciona. Aunque no veo ningún uso en este modelo FOLDEREX que creaste. Una cosa de loco como tú. Tenga un buen día.

Regards, saludos.

karinha wrote:hahaha, Silvio, you're not boring. If it works for you, use it. If it doesn't work for you, don't use it. your model does not work. Mine works. Although, I don't see any use in this FOLDEREX model that you created. Crazy thing like you. Have a good day.

jajaja, Silvio, no eres aburrido. Si te funciona, úsalo. Si no te funciona, no lo uses. tu modelo no funciona. El mío funciona. Aunque no veo ningún uso en este modelo FOLDEREX que creaste. Una cosa de loco como tú. Tenga un buen día.

Regards, saludos.