Build 260

[rdonnay]

A cosmetic thing still seems to be in there (#1281 in your README).

I am not sure what you mean. When a menu wraps it reduces the size of the drawingArea, but that's what it always did.

Can you take a snapshot?

[Tom]

The menu does not wrap (see picture). If I reduce the number of menu entries by one, the space is correct.

[rdonnay]

The menu does not wrap (see picture). If I reduce the number of menu entries by one, the space is correct.

I am confused. Why is the menu supposed to wrap? That should happen only when the dialog width is decreased to less than the menu width.

Please show me a snapshot of the correct window.

[Tom]

You were talking about wrapping menus.

If I take out one menu entry, the dialog fits correctly:

[rdonnay]

Interesting. I will have to write a test program to figure this out.

I realize now what is happening here.

I added more tests of the system metrics to insure that the fit of the dialog was correct.
This had to take into consideration the height of the menu: GetSystemMetrics(15).

When the dialog is first created, it has a default width of 640 pixels. Your menu was longer than 640 pixels, therefore it wrapped the menu.
Later in the code, the ::AutoFit() method is called and it determines the size of the dialog and the perimeter padding based on the height of the menu, plus other metrics. GetSystemMetrics() will return a value 2x the normal height of the menu in this case.

I think that the best way to overcome this problem is to use the WINDOWWIDTH clause of DCGETOPTIONS and set it to a value higher than the width of your menu.

Look at the below sample program. It will display the dialog correctly. If the DCGETOPTIONS is commented out, it will display the dialog with extra space at the top.

Code: Select all

#INCLUDE "dcdialog.ch"

FUNCTION Main()

LOCAL GetList[0], GetOptions, aMenu[12], oMenuBar, i

DCMENUBAR oMenuBar
  FOR i := 1 TO Len(aMenu)
    DCSUBMENU aMenu[i] PARENT oMenuBar PROMPT 'Menu ' + Alltrim(Str(i))
  NEXT

@ 0,0 DCSTATIC TYPE XBPSTATIC_TYPE_RECESSEDBOX ;
      SIZE 1000,500 PIXEL

DCGETOPTIONS WINDOWWIDTH 1000

DCREAD GUI FIT TITLE 'Menu Test with Fit' OPTIONS GetOptions

RETURN nil

* ---------

PROC appsys ; return

[Tom]

I wrote a test program four years ago, when we first discussed this issue.

http://bb.donnay-software.com/donnay/vi ... ?f=2&t=188

[rdonnay]

I wrote a test program four years ago, when we first discussed this issue

Oops. I just now saw your posting. Too late. I wrote a test program. See previous posting.
It has the answer to your problem.

[Tom]

Yes, setting a WINDOWWIDTH in DCGETOPTIONS solves it! Thanks!

[rdonnay]

Getting back to your DC_XbpStatic():draw() problem.

I removed the below code as you requested.

GraPathBegin( oPS )
GraBox( oPS, {4,2}, {::CurrentSize()[1]-4,::CurrentSize()[2]-2} )
GraPathEnd( oPS )
GraPathClip( oPS, .T. )

However, I still think you should add ::ownerDrawBlock := {||nil} to your custom class.
I'll bet you will have less fatal errors.

[Tom]

I'll bet you will have less fatal errors.

If not - you pay all my beers at the eXpress-DevCon. Okay?