Painting bottons

[Intel_C_Intel]

Painting bottons and controls

The solution of Mr. Jugoslav Dujic with Xflogm is very elegant and should be used for painting bottons and controls. Another simple way of painting bottons with icons or bmp's is included.
I am also including a subprogram for changing fonts in controls.
Both of them work well with DFlib (Quickwin) or Windows projects(DFWin).
My questions:
By default, writing of text in controls uses opaque mode. I tried to change to
transparent mode using:
intret= SetBkMode(hdc,transparent)
It does not show any error, but it does not work either. How can I do it?

How can I use rich text edition boxes?

How can I use rich text documents?

! **************************************************************
! Subroutines de OPY
! Painting ICON or BMP

SUBROUTINE PaintBotton(&
Dialogo, & ! Dialog structure
IDC_BOTON, & ! Botton name
File_Name, & ! File name (Fortran string)
IconorBmp & ! 'Icon' or 'Bmp'
)

Use dfwin
Use xflogm ! or dflogm

implicit none

type (dialog) Dialogo
integer IDC_BOTON,lenght
integer hwnd,hDlg,hwndCtl,nIDDlgItem
Integer cxDesired/0/,cyDesired/0/,intret
Integer hInst, hImagen
Character*100 File_Name
Character*101 CFile_Name
Character*32 IconorBmp
Integer Image

! Name of File: CString
CFile_Name = TRIM(ADJUSTL(File_Name))//CHAR(0)

!Handle of module instance.
hInst=GetModuleHandle(NULL)

!Handle of dialog
hDlg = Dialogo % hwnd

cxDesired=32 ! // desired width
cyDesired=32 ! // desired height

Select Case(IconorBmp)
Case('ICON','Icon','icon','IMAGE_ICON','image_icon','Image_Icon','Image_icon')
Image=IMAGE_ICON
Case('BMP','Bmp','BITMAP','BitMap','IMAGE_BITMAP','image_bitmap','Image_bitmap','Image_Bitmap')
Image=IMAGE_BITMAP
End Select
hImagen = LoadImage(&
hInst, & ! // handle of the instance containing the image
CFile_Name, & ! El archivo tiene que estar en el misamo directorio del .exe
Image, & ! // type of image
cxDesired, & ! // desired width. When not using default size
cyDesired, & ! // desired height. When not using default size
LR_DEFAULTSIZE .OR.LR_LOADFROMFILE ) ! // load flags

hwndCtl= GetDlgItem(&
hDlg, & ! // handle of dialog box
IDC_BOTON ) ! // identifier of control
nIDDlgItem = GetDlgCtrlID(&
hwndCtl ) ! // handle of control
intret= SendDlgItemMessage(&
hDlg, & ! // handle of dialog box
nIDDlgItem, & ! // identifier of control
BM_SETIMAGE, & ! // message to send
Image, & ! // first message parameter: Type of image
hImagen ) ! // second message parameter: handle to the image

RETURN
END SUBROUTINE PaintBotton
!*********** *****************************************************************
!
!SUBROUTINE : UpdateFont ( &
! Dialogo, &
! IDC_CONTROL,&
! faceName, &
! pointSize, &
! negrita, &
! cursiva )
!
! PURPOSE: Updates the font in the Edit box
!
! COMMENTS:
!
!****************************************************************************

SUBROUTINE UpdateFont( Dialogo, IDC_CONTROL,faceName, pointSize, negrita, cursiva )

Use dfwin
Use xflogm ! Must use Mr. Jugoslav Dujic version to color the font

type (dialog) Dialogo
inte

[Jugoslav_Dujic]

Doh, I think I owe you few clarifications... and you owe me code bracketed in

 ... 

tags because this one is quite unreadable (while Compaq owes us all improvements in their Forum software, but that's an old topic). I'll probably be able to answer your question about painted buttons then. (Note that you message also break the length limit),

Idea behind DFLOGM is that Win32 DialogBox function is modal, so user cannot set any values before nor retrieve any values after that; on DlgInit DFLOGM parses dialog resource and creates a list of all controls (IIRC its type controltype) Dialog%list. Each controltype contains logical, integer or string data. User can DlgSet control values, effectively writing into Dialog%list; when DlgModal is run, PRIVATE DialogProc in DFLOGM manages that Dialog%list is always up-to-date with state of dialog controls. After closing the dialog, Dialog%list is available to user via DlgGet.

This design has two flaws: 1) Only predefined control properties and control types are available to user 2) It duplicates memory, which is especially true for strings -- Windows already allocates and manages that. As a consequence, if you have RichEdit or ListView, you can forget about DFLOGM (unless you intend to add wrappers yourself). For example, for font management, you have to allocate and manage an additional Dlg%List%intvalue for each control type containing its hFont, take care about creation/destruction of font objects and wrapping

Well, I have an intention to rewrite DFLOGM from scratch using mechanism similar to MFC (which would also quite reduce its size):

- On DlgInit, create an invisible modeless dialog;

- DlgModal would actually ShowWindow, disable all thread windows (so to have appearance of a modal dialog) and enter a message loop

- DlgSet/DlgGet would be just wrappers for SendMessage

- DlgUnInit would just DestroyWindow.

- Controls will have buffers only for callbacks (DlgSetSub). Private DialogProc would manage these and call appropriate user-provided callbacks


Such design would avoid the above-noted flaws -- first, no extra memory allocated and second, if a control or its properties aren't wrapped, SendMessage will do... only, I have to find some free time to do it (though DlgSet/DlgGet wrappers are finished)... sorry, I can make no promise about release date.

Note, however, that SendMessage works with the existing DFLOGM provided it's called from a callback function.

Regards
Jugoslav