Owner draw buttons

[Anonymous]

Hi All,
in my BC++ 5.2 OWL application I have created the following dialog in order to let the user to choose one of the basic 8 colors. It works well but I'm not able to modify the aspect of the button clicked so that the user can realize the button choosen. Is there a way to achieve this?

This is the resource code:

IDD_GEA_SYMB_COLORS DIALOG 945, 66, 287, 51
STYLE DS_MODALFRAME | DS_3DLOOK | DS_CENTER | DS_CONTEXTHELP | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX
CLASS "bordlg_gray"
CAPTION "-- Colori simboli punti per Google Earth --"
FONT 8, "MS Sans Serif"
{
 CONTROL "", IDC_BLACK, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 8, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTBLUE, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 31, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTCYAN, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 54, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTGREEN, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 77, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTMAGENTA, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 100, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTRED, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 123, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_LTYELLOW, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 146, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDC_WHITE, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 171, 27, 15, 15, WS_EX_CLIENTEDGE
 CONTROL "", IDOK, "BorBtn", BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP, 197, 22, 33, 21, 0
 CONTROL "", IDCANCEL, "BorBtn", BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP, 245, 22, 33, 21, 0
 CONTROL "Cliccare la casella del colore desiderato e confermare con OK", -1, "static", SS_LEFT | WS_CHILD | WS_VISIBLE, 8, 9, 228, 10
}

Thanks in advance,

Gianni

---

Moderator: Formatted the code.

[Sebastian Ledesma]

Hi Gianni:

You are using BWCC buttons, they are fixed size.
You need to change to GlyphButtons that allow to define a custom glyph and use any size.

Sebas

[Sebastian Ledesma]

You can take a look at the 'Control colors' example at http://www.jahanshahi.ws/owl.htm
There also other examples using GlyphButtons.

Also I suggest to upgrade to at least OWLNext 6.30

Sebas

[Gianni Rossi]

Hi Sebastian,

thanks for your help, I'll try what you suggested.

Regarding to port my application to OWLNext, I really would like to do so,
but it's a huge application and I have no time nor the experience for this
task. In fact, I also asked here if someone is available to do this job on
commission. Jogy seemed to be willing to do the job for a certain amount,
but then I never heard from him any longer.

If you have any idea on this matter you are welcome.

Ciao.

Gianni Rossi
Tecnobit S.r.l.
Via B. Sacchi, 9
36061 Bassano del Grappa (VI)
Italy

---

Moderator: Snipped superfluous quoted content.

[Ognyan Chernokozhev]

Hello,

My apologies ... I ported the code to OWLNext 6.30, and then, since BC5.02 was being very unstable and almost impossible to work with, I started to port the code to compile with VC2010, which required quite a few changes. I finally was able to compile and build all, but then the application crashed on startup, I tried to chase it, but then become occupied with other issues ....

I can send you and Vidar the code with my changes, so he can continue from there, and I also have documented some of the conversion issues I encoutered in the wiki, including how to use BDE from VC: https://sourceforge.net/p/owlnext/wiki/Migrating_from_BC_to_VC/

Jogy

[Gianni Rossi]

Hi Jogy,

Thanks for your feedback.

Yes, it would be great if you can transfer the project to Vidar since he
said he has the time to complete it. If so, would you be so kind as to
inform Vidar about both the topics to implement and the fee we agreed? So,
maybe you and Vidar could spread the fee considering the job already done.

Vidar,

Of course I’m also willing to revise the whole agreement if you think that
it’s necessary.

Looking forward to your reply.

Bye for now.

---

Moderator: Snipped superfluous quoted content.

[Gianni Rossi]

Hi Jogy and Vidar,

Are you still interested in my proposal to migrate my BC++ 5.02 OWL application to OWLNext?

Please let me know because I really need to move forward on this solution since BC++ 5.02 is everyday more instable as the application grows.

Please let me also know if you think that we better talk about this in private, in which case please reach me at:

Email: g.rossi@tecnobitmail.com g.rossi@tecnobitmail.com

Skype g.rossi.tb (but currently I’ve moved to Slack, please let me know if you use it).

Ciao.

---

Moderator: Snipped superfluous quoted content.

[Ognyan Chernokozhev]

Hi,

I have prepared 3 sets of source code:
1. The original BC5.02/OWL5 that Gianni provided me
2. Initial port to BC5.02/OWL630
3. Current port to VC2010/OWL630

I can send them to Vidar.

This way by running a dif tool the changes in each port can easily be seen ...
Also one of the issues with VC2010 (or newer) would be to find corresponding versions for all 3rd party libraries that are used

Jogy

[Vidar Hasfjord]

Hi Gianni,

Yes, I am still interested in taking on the work, and I will contact you in private with my terms and proposal for how to procede.

In the meantime, I suggest that you review Jogy's work on the project. I advice that you fully settle this phase of the work, including payment of all outstanding fees, and preferably, come to agreement on terms of any further support of the work (e.g. warranty, questions and clarifactions regarding the work performed, as well as terms of any further assistance in resolving related issues, if needed).

[Gianni Rossi]

Hi Jogy and Vidar,
I'm replying here to you both.

Yes, I am still interested in taking on the work, and I will contact you
in private with my terms and proposal for how to procede.

Good, I'm looking forward to your proposal.

In the meantime, I suggest that you review Jogy's work on the project.

Ok, but I need instructions on how to do this task because I'm completely
inexpert about OWLNext, but please see below about the changed code.

I advice that you fully settle this phase of the work, including payment
of all outstanding fees...

Ok, Jogy, please let me know about this point.

... and preferably, come to agreement on terms of any further support of
the work (e.g. warranty, questions and clarifactions regarding the work
performed, as well as terms of any further assistance in resolving related
issues, if needed).

Vidar, I would prefer that Jogy passes everything to you and then setup a
unique agreement with you if Jogy will no longer be involved in the project.

1. The original BC5.02/OWL5 that Gianni provided me
2. Initial port to BC5.02/OWL630
3. Current port to VC2010/OWL630
   I can send them to Vidar.
   This way by running a dif tool the changes in each port can easily be seen
   ...

The problem is that in the meanwhile I have added a lot of new code to the
project. Do you mean that the dif tool you mention can programmatically
update the porting?

Also one of the issues with VC2010 (or newer) would be to find
corresponding versions for all 3rd party libraries that are used

I don't think this is difficult to solve because almost all the 3rd party
libraries included in the project were made for VS and I had to make them
compatible for BC++ via IMPLIB or other methods, i.e. I've always had the
opposite problem.

Waiting for your reply, thanks.

Ciao.

---

Moderator: Snipped superfluous quoted content.

[Ognyan Chernokozhev]

I advice that you fully settle this phase of the work, including payment
of all outstanding fees...
Ok, Jogy, please let me know about this point.

I make no claims and will freely provide Vidar with all changes I have made and if needed, explanations and comments on them.

The problem is that in the meanwhile I have added a lot of new code to the
project. Do you mean that the dif tool you mention can programmatically
update the porting?

It is possible to make a 3-way merge between your current conde, and my changes. Hopefully most of them will automatically be merged, only if there are conflicts there will be a need for manual merging.

Also, the 3 sets of sources can just help as a guide as what changes were needed. Some of them were trivial, and amount to a simple search&replace, and for some others it is possible that Vidar can find a better solution.

Jogy

[Vidar Hasfjord]

By the way, regarding visual indication of the selected color in your custom colour dialog, try adding the WS_BORDER style to the selected ownerdraw button. I think that is what the classic standard color dialog does, which shows up as a thin black border around the selected color.

[Gianni Rossi]

Hi Vidar,

I've tried to add WS_BORDER to the buttons in the resource:

CONTROL "", IDC_LTBLUE, "button", BS_OWNERDRAW | WS_CHILD | WS_VISIBLE |
WS_BORDER, 31, 27, 15, 15

but this does not show the thin border that you say.

Do you mean that I have to change something in my overridden EV_WM_DRAWITEM
handler for the selected button?

Thanks.

---

Moderator: Snipped superfluous quoted content.

[Alain Danteny]

Hi Gianni,
Sorry to being late and mostly offline...
For your OWNERDRAW button, you have to handle EVERYTHING when it comes to drawing.
So, yes, you have to deal with it inside your EV_WM_DRAWITEM handler, ie
check the itemState member of the DRAWITEMSTRUCT 'dinfo'
dinfo.itemState & ODS_SELECTED
dinfo.itemState & ODS_FOCUS
and draw accordingly (could be in an offscreen bitmap, then blitted to TDC dc(dinfo.hDC).

[Alain Danteny]

Furthermore, if you add the WS_BORDER style, this will not be handled by the EV_WM_DRAWITEM message: this drawing is handled by the EV_WM_NCPAINT handler.
Then, if you want to completely customise the look, you need to handle those messages :
EV_WM_NCCALCSIZE
EV_WM_NCPAINT
so you can:
1- create the WindowRgn (from the GetWindowRect() call)
2- create the ClientRgn (from the GetClientRect() call,offset by the Border width
3- subtract the ClientRgn from the WindowRgn to get 'the border area' only
4- paint this Rgn however you want.
something like

TRect UrControl::GetInnerRect() const
{
    TRect rect=GetWindowRect();
    //translate origin TopLeft=0,0
    rect.Offset(-rect.left,-rect.top);
    //add margins according to STYLE: let Windows do that for us...
    TWindowDC dc(GetHandle());
    NCCalcSize(dc,rect);
    return rect;
}

void UrControl::NCPaint(TWindowDC& dc)
{
    TRect winRect=GetWindowRect();
    winRect.Offset(-winRect.left,-winRect.top);
    //winrect has now TopLeft=0,0
    TRect cliRect=GetInnerRect();

    if (cliRect!=winRect){
        //there is some kind of 'border' around the Cleint area: subtract it
        TRegion winRgn(winRect);
        TRegion cliRgn(cliRect);
        winRgn ^=cliRgn;  //<owl/gdiobject.h>

        dc.SelectClipRgn(winRgn);
        bool enabled=::IsWindowEnabled(GetHandle());
        COLORREF textcolorref=GetTextColor(enabled);///<TO DO here

        dc.TextRect(winRect,textcolorref);
        ::SelectClipRgn(dc.GetHDC(), NULL);
    }
}

void UrControl::EvNCPaint(HRGN)
{
    TWindowDC dc(GetHandle());
    NCPaint(dc);
}

void UrControl::NCCalcSize(TWindowDC& dc,RECT& rect) const
{
    UNREFERENCED_PARAMETER(dc);
    int dx=0;
    int dy=0;
    if ( (Attr.Style & WS_BORDER)==WS_BORDER){
        dx+=::GetSystemMetrics(SM_CXBORDER);
        dy+=::GetSystemMetrics(SM_CYBORDER);
    }
    rect.left   += dx;
    rect.top    += dy;
    rect.right  -= dx;
    rect.bottom -= dy;
}

/**
If fCalcValidRects  is TRUE, lParam points to an NCCALCSIZE_PARAMS structure
that contains information an application can use to calculate the new size
and position of the client rectangle.

If fCalcValidRects  is FALSE, lParam points to a RECT structure that contains
the new coordinates of the window that has been moved or resized.
This is equivalent to rgrc[0] of an NCCALCSIZE_PARAMS structure.

Return Values

If the fCalcValidRects parameter is FALSE, the application should return zero.
If fCalcValidRects is TRUE, the application can return zero or a valid combination
of the following values:
*/
uint UrControl::EvNCCalcSize(bool calcValidRects, NCCALCSIZE_PARAMS& calcSize)
{
    //call base class first
    uint result=UrBaseControl::EvNCCalcSize(calcValidRects, calcSize);
    if (calcValidRects){
        TWindowDC dc(GetHandle());
        //do our own calculation
        NCCalcSize(dc,calcSize.rgrc[0]);
        result=WVR_REDRAW;
    }
    return result;
}

[Gianni Rossi]

Hi Alain,

thanks for your detailed explanation, but it seems too complicated to me for
just this task because I have not enough experience in handling all those
Windows events and stuff. I’m looking for something simpler, unless you
could send me a complete example.

---

Moderator: Snipped superfluous quoted content.

[Alain Danteny]

That's not 'so' complicated, really.
source\owlcoreTFloatingFrame, and TTinyCaption are a good starting point.

[Vidar Hasfjord]

Let me add to Alain's great advice about painting:

In addition to the custom painting of your ownerdraw buttons, you will have to handle the selection logic. I guess you want the colour buttons to function as a radio button group. However, there is no way to combine the automatic radio button logic with ownerdraw buttons. Search the Internet for ownerdraw radio buttons for more details.

A simpler alternative would be to list your colours in an ownerdraw listbox. An ownerdraw listbox will still handle the selection logic automatically. And the custom painting would probably be simpler.

Another benefit from using a listbox is that you can reuse your code in a dropdown list and perhaps eliminate the need for the colour selection dialog altogether. For example, if you have a button in a parent dialog, or on a toolbar, that opens the colour selection dialog, you can replace that button and the dialog by the dropdown colour list instead, for a simpler user interface.

[Alain Danteny]

Indeed, an OwnerDraw Listbox (or combo) is easier to handle (drawing, selection, aso...) and maybe more re-usable.
Back in BC5.02 era, there was a good project about a colorpopup ownerdraw (listbox or button or static, I can't remember) . If I can put my hands back on it (a couple of GB of archive to deal with :D ), I'll publish it here...

[Vidar Hasfjord]

An even simpler alternative: Use the standard colour selection dialog, unless you really need to restrict the set of colours. Also note that the standard dialog lets you define up to 16 custom colours.

[Gianni Rossi]

Hi Vidar,

Yes, I just need to restrict the options to those 8 colors, that’s way I
tried to implement that dialog. As I said, everything works fine except that
the user has not the evidence of which color is selected.

---

Moderator: Snipped superfluous quoted content.

[Sebastian Ledesma]

I've made the work of a Owner Draw combobox (wich in my case was derived from a Owner Draw listbox), and after that I've made a deriverd class TColorComboBox wich allowed to select a color from a drop down menu.
It's not hard and a good learning leasson.

As short way, I suggest to take a look at OWL Color Picker at Luiggi site. It was traslated from MFC and I've enhaced and traslated to OWLNext:
http://www.luigibianchi.com/owl.htm
I will send a sample code to Mohsen so all can use it.

[Gianni Rossi]

Hi Sebastian,

Your color Owner Draw combobox could be fine for this 8-only colors to
choose from. Is there a chance to get it?

Anyway, I have also to develop another color dialog box which permits to
choose between 256 colors (those ones used by AutoCAD) and of course I need
to show the user the color picked, like that in the image attached.

I mean, I don’t want that the user can navigate between all possible colors
(RGB combinations) but that the choice is only to select one of the 256
colors.

Any idea or source code will be greatly appreciated, I’m also willing to pay
a reasonable fee if someone could provide me a complete example for BC++ 5.2
/ OWL.

Thanks in advance.

---

Moderator: Snipped superfluous quoted content.

[Alain Danteny]

Gianni,
Here you go with a quick&dirty class I wrote meanwhile.
Derived from TControl.
Act like a CheckBox.
That should be BC5.02-compatible.
Enjoy ;)

[Gianni Rossi]

Hi Alain

Your code seems a great solution, thanks. Would you also be so kind as to
tell me how to define you UColorControl controls in my dialog resource?

Thanks again.

---

Moderator: Snipped superfluous quoted content.