FiveTech Software tech support forums

The 2015 clause of the MENU command breaks MENUINFO behaviour (the width of the menu is not enough for the MDICHILD window title).

This is a sample of the problem:
EMG

Enrico,

Many thanks for the bug report and for the example.

We are going to review it asap

Thank you, Antonio!

EMG

I add that in some cases even the height of the menuitem is not enough for the menuitem text.

EMG

All features fixed, solved

----------------------- SPANISH --------------------------

La creación de los items en los menús cuando una ventana hija es creada, no la realiza Fivewin, es realizada por el sistema automáticamente dependiendo del valor de nMenuInfo que pasamos a esa function.
Cuando el nuevo item es creado por el sistema ( ya saben que la característica MDI es manejada por el propio sistema y ya en desuso ), no disponemos del objeto TMenuItem para poder manejar sus propiedades, entre ellas el prompt del item, que en el mensaje WM_MEASUREITEM no es posible obtener, por lo que no es posible determinar su longitud y poder realizar el correspondiente ajuste del ancho del menú en el que se ubica. Sólo es posible determinar el prompt de un item, aunque el nuevo item sea generado por el sistema, en el mensaje WM_DRAWITEM, pero el mensaje WM_MEASUREITEM es ejecutado antes que el mensaje WM_DRAWITEM, por lo que sus dimensiones no han podido ser calculadas y es dibujado con el ancho que ya tuviera el menú en el que se va a ubicar.
Ahora he utilizado el caption de la nueva ventana hija creada para que pueda calcular las dimensiones del item.
Como pueden entender, no es una forma de solucionarlo relacionada con las estructuras y metodologías de los menús, pero ha sido la única forma que he encontrado de poder solucionarlo.
Si alguien encuentra la forma de poder encontrar el prompt de un item a partir del valor de la estructura
typedef struct tagMEASUREITEMSTRUCT {
UINT CtlType;
UINT CtlID;
UINT itemID;
UINT itemWidth;
UINT itemHeight;
ULONG_PTR itemData;
} MEASUREITEMSTRUCT, *PMEASUREITEMSTRUCT, *LPMEASUREITEMSTRUCT;

que es pasada como parámetro lParam en el mensaje WM_MEASUREITEM, por favor, comparta su solución, para poder implementarlo de una forma más "limpia"

------------------------------------- ENGLISH -------------------------------


The creation of the items in the menus when a child window is created, not done by Fivewin, is performed by the system automatically depending on the value of nMenuInfo that we pass to that function.
When the new item is created by the system (you already know that the MDI feature is managed by the system itself and already in disuse), we do not have the TMenuItem object to be able to manage its properties, including the item's prompt, which in the message WM_MEASUREITEM is not possible to obtain, so it is not possible to determine its length and be able to make the corresponding adjustment of the width of the menu in which it is located. It is only possible to determine the prompt of an item, even if the new item is generated by the system, in the WM_DRAWITEM message, but the WM_MEASUREITEM message is executed before the WM_DRAWITEM message, so its dimensions could not be calculated and it is drawn with the width that already had the menu in which it is going to be located.
Now I have used the caption of the new child window created so that I can calculate the dimensions of the item.
As you can understand, it is not a way to solve it related to the structures and methodologies of the menus, but it has been the only way I have found to be able to solve it.
If someone finds a way to find the prompt of an item based on the value of the structure
typedef struct tagMEASUREITEMSTRUCT {
  UINT CtlType;
  UINT CtlID;
  UINT itemID;
  UINT itemWidth;
  UINT itemHeight;
  ULONG_PTR itemData;
} MEASUREITEMSTRUCT, * PMEASUREITEMSTRUCT, * LPMEASUREITEMSTRUCT;

which is passed as parameter lParam in the message WM_MEASUREITEM, please, share your solution, to be able to implement it in a more "clean" way

Please note that there is no problem when 2015 clause is not used.

EMG

Enrico Maria Giordano wrote:Please note that there is no problem when 2015 clause is not used.

EMG

It is logical
When the menus are not OWNERDRAW (without styles, fonts, etc.), the menus are painted by the system (Windows) and not by Fivewin.

Ah, ok. So, without any clauses (2015 or similar) the menu gets a system look?

EMG

Enrico Maria Giordano wrote:Ah, ok. So, without any clauses (2015 or similar) the menu gets a system look?

EMG

Yes, from September 2017 version ( read whatsnew )

* MENUS: By default, when no style is selected, the menus have the appearance of those defined by the OS
   because OWNERDRAW is not applied internally to paint the items. Same high and wide as the system menus.
    If you want to add any clause to a menu without defining any style, it is necessary to add the COLOR clause
   in the definition of our menu

    Example:
MENU oMenu
MENUITEM "First"
MENU
MENUITEM "My Test" BOLD
MENUITEM "My Menu" ITALIC
ENDMENU
ENDMENU

In this case, the BOLD and ITALIC clauses are ignored
    But, if the menu is defined as:

MENU oMenu COLORS

All clauses are active, if defined, even if no style has been defined

In any previous version, all the menus were painted by Fivewin.

Great, thank you.

EMG