dcgetoptions ... SCALEFACTOR and TABpages

[bwolfsohn]

By the way: Scaling the app is a user option in our applications. If this is set, there is only one factor calculated. Since the app layout is based on 1024 x 768, the factor is calculated using DC_GetWorkArea(). If the width is higher than 1024, like 1400, the width factor would be 1.37. If the height is only 900, which creates the factor 1.17, this factor is used (first 4 parameters) - and vice versa. This creates a perfectly scaled app, while setting different factors for width and height may create something really ugly.

The scalefactor is set only once, using DC_GetOptDefault().

Tom,
We've been using scaling for years, but it's been problematical at times...

Can you show us a bit of code to illustrate what your are referring to...
When you scale, are you limiting the rescaling to maintain that aspect ratio ?
How are you accomplishing that ??

looking forward to seeing you at the end of the month...

[Tom]

Hi, Brian.

How are you accomplishing that ??

This is quite simple. "DC_GetWorkarea()" gives you an array with four elements - lower left position (1,2 - 0,0 in most cases) and upper right corner (3,4), so 3-1 and 4-2 represent the available desktop size (resolution minus taskbar). Our app is layouted to fit 1024 x 768. A scale factor for the width would be (DC_GetWorkArea()[3]-DC_GetWorkArea()[1])/1024, for the height (DC_GetWorkArea()[4]-DC_GetWorkArea()[2])/768. The lower number is set as the scale factor (SCALEFACTOR {nFactor,nFactor,nFactor,nFactor,.T.,.F.}). The app is "zoomed", width or height (or, if ideal, both) take the available area, but nothing is "stretched".

[rdonnay]

Brian and I just had a phone conversation about real estate management and it gave me some ideas on how items can be automatically moved around using concepts similar to CSS and DIV tags in HTML.

I am going to look into this possibility.

It will be similar to RESIZE rules but instead will be RELOCATE rules.

Maybe I can even apply CSS styling at some point.

[skiman]

I assume the problem sits inside "BuildGets". You are merging getlists there, right?

Yes, as in the Collection sample.

[skiman]

I assume the problem sits inside "BuildGets". You are merging getlists there, right?

Yes, as in the Collection sample.

I checked the Xsample_144 where tabpages are created the same way. No problem when using SCALEFACTOR.

[skiman]

Chris -

If you can give me your full application, I can probably help you with this.

Roger

Hi Roger,

No problem to give you my full application, but this will take some time. You will also need a full installation, otherwise it won't start. If you have time, maybe we could use teamviewer to look at my system?

[richardc]

I had the same problem with tab pages except my font was reducing in size instead of increasing in size. I was using RELATIVE on all of the tab pages. I resolved the issue by explicitly defining the font for each page. I was using Lucida font and changed them all to Arial. This resolved my problem.

@ 0,0 DCTABPAGE oEap ;
CAPTION 'EAP' ;
WHEN {||clplan->Eap .or. oRecord:eap} ;
COLOR {||{GRA_CLR_BLACK,GRA_CLR_PALEGRAY}} ;
FONT '12.Arial Bold' ;
RELATIVE oContact

Richard

[rdonnay]

I had the same problem with tab pages except my font was reducing in size instead of increasing in size. I was using RELATIVE on all of the tab pages.

That makes sense.

When a tabpage is relative to another tabpage, it inherits some of its properties, including width, tab width and font.
After that, the scale factor is applied. So I can see why the font would grow with each tabpage. Your solution sounds like a good workaround.
I will need to fix this in the code.

[skiman]

Hi,

It looks as the 'growing' is happening here:
ABout line 2982 in _dcgetbx.prg

Code: Select all

   IF ::scaleFactor[5] .AND. IsMethod(oXbp,'SetFont') .AND. ;
         !oXbp:isDerivedFrom('DC_XbpGet') .AND. !oXbp:isDerivedFrom('DC_XbpStatic') 
      oFont := oXbp:setFont()
      IF Valtype(oFont) = 'O'
         cFont := Alltrim(Str(Round(oFont:nominalPointSize * ::scaleFactor[3],0))) + ;
            '.' + oFont:familyName
         oXbp:setFontCompoundName(cFont)
      ENDIF
   ENDIF

When I check the xsample_144, there is also the 'relative to'. There it is working.

A strange thing I saw is the following:
- I added a wtf cFont in the above code, and I recompiled. With the new dclipx.dll the debug window appears with my application. With the xdemo.exe and also the new dclipx.dll, the debug didn't appear with xsample_144. I don't understand how this can happen? I would expect that the xsample_144 should also pass by the same function in _dcgetbx.prg?

[skiman]

Hi,

This drives me crazy, if I wasn't already.

I had some issues in my application with the scalefactor, and now I have the following code:

Code: Select all

function zoekklant20()
local getlist := {} ,  lOk

@ 1,1 dcsay "Zoek klant"

dcread gui fit addbuttons to lOk
return nil

Below you see the result at the left with a scalefactor of 1.2. At the right without scalefactor.

scalefactor.png (44.16 KiB) Viewed 12636 times