headers
Manish Gupta | 1 Jan 2003 14:21
Picon
Favicon

CustomDrawn TreeView

Hello Wtl,

I'm doing a custom drawn tree view control. I use both CDDS_ITEMPREPAINT and 
CDDS_ITEMPOSTPAINT.

During CDDS_ITEMPREPAINT, I just change the font(sometimes), textcolor and 
text backcolor and return ( CDRF_NOTIFYPOSTPAINT | CDRF_NEWFONT ).

During CDDS_ITEMPOSTPAINT, I change the default (+) icon that windows draw 
and replace it with a custom icon. I also do some drawing around the item 
rect. So far so good.

But, when I call DeleteAllItem() and repopulate the tree, the item's text 
does not show up. All other things appear fine including the backcolor, the 
icon that i paint and the drawing around the item rect. They reappear when I 
resize the dialog. I've tried using Invalidate() and UpdateWindow() but this 
does not seem to help. It seems to be related to the call to DeleteAllItem() 
because if I don't call this things work as expected. But I can't live with 
not deleting the items. Any clues anyone?

Thanks for all you help
Manish

_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*. 
http://join.msn.com/?page=features/junkmail
Permalink | Reply | 0 comments |
headers
Jim Barry | 3 Jan 2003 14:16
Favicon

Re: WTL Bug: CFolderDialog

allancady@... wrote:
> pT->m_hWnd is set on entry to BrowseCallbackProc(), then 
> it's cleared on exit -- I can't see why it's cleared. This makes 
> the static callback fail if it is re-entered, which will happen if 
> you make more than one call to any of the SetXXX() functions 
> from within OnInitialize.  

I ran into this exact problem sometime last year. I reported it directly toNenad Stefanovic, who agreed
that it is an oversight. The problem may be addressed in a future version of WTL; in the meantime it sounds
like you already have a good idea how to work around it.

--

-- 
Jim Barry
MVP for Windows SDK
Permalink | Reply | 0 comments |
headers
jldean1 | 3 Jan 2003 22:29
Picon
Favicon

Moving / Resizing a tab control

I have a tab control (CTabCtrl) implemented within an activex 
control. Its default position seems to be fixed in relation to the 
view on which it is hosted. Its top left corner is fixed to the 
middle top of the activex control. Is there a any way to 
programatically move the tab control over to the top left corner of 
the activex control's area?

Thanks!
James
Permalink | Reply | 0 comments |
headers
Menningen, Kevin | 3 Jan 2003 23:09

RE: Moving / Resizing a tab control

Assuming the activex control is a composite control, you can use WTL's
CDialogResize class to move/resize objects correctly. 

Good luck!

--Kevin

-----Original Message-----
From: jldean1@... [mailto:jldean1 <at> yahoo.com]
Sent: Friday, January 03, 2003 3:29 PM
To: wtl@...
Subject: [wtl] Moving / Resizing a tab control

I have a tab control (CTabCtrl) implemented within an activex 
control. Its default position seems to be fixed in relation to the 
view on which it is hosted. Its top left corner is fixed to the 
middle top of the activex control. Is there a any way to 
programatically move the tab control over to the top left corner of 
the activex control's area?

Thanks!
James

To unsubscribe from this group, send an email to:
wtl-unsubscribe@...

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 501 comments |
headers
Nenad Stefanovic | 4 Jan 2003 12:59
Picon
Favicon

RE: WTL Bug: CFolderDialog

Exactly right. I will probably removed those lines, and add a note about
HWND being valid only in handler functions.

Cheers,
Nenad

-----Original Message-----
From: Jim Barry [mailto:jim@...] 
Sent: Friday, January 03, 2003 5:16 AM
To: wtl@...
Subject: Re: [wtl] WTL Bug: CFolderDialog

allancady@... wrote:
> pT->m_hWnd is set on entry to BrowseCallbackProc(), then
> it's cleared on exit -- I can't see why it's cleared. This makes
> the static callback fail if it is re-entered, which will happen if 
> you make more than one call to any of the SetXXX() functions 
> from within OnInitialize.  

I ran into this exact problem sometime last year. I reported it directly
to Nenad Stefanovic, who agreed that it is an oversight. The problem may
be addressed in a future version of WTL; in the meantime it sounds like
you already have a good idea how to work around it.

--

-- 
Jim Barry
MVP for Windows SDK

To unsubscribe from this group, send an email to:
wtl-unsubscribe@...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Selormey | 4 Jan 2003 15:18

Exiting Application

Hello All,
I am currently porting an application from MFC to MC++ but decided to
reimplement the rendering (using GDI/GDI+ with WTL).

I am using VS.NET 2003 Final Beta. For reasons, I cannot tell, whenever,
I exit the application, it continues to exist in memory. I debugged and
found
out that the application is locked in the Run() method ::GetMessage() line.
I then decided to use PostQuitMessage(0) in the WM_CLOSE handler and
everything works normal.

The main application uses 4 normal DLLs developed with ATL/WTL.

Any idea as to what is going wrong?

Best regards,
Paul.
Permalink | Reply | 2 comments |
headers
Nikos Bozinis | 4 Jan 2003 16:29
Picon
Favicon

Re: Exiting Application

if we assume that the problem hasn't got anything to do with the 
compiler you are using, it must be something in the code

by default (in WTL) PostQuitMessage is sent from the mainframe's 
WM_DESTROY handler. What are you doing in your WM_DESTROY?

--- In wtl@..., "Paul Selormey" <paul <at> t...> wrote:
> Hello All,
> I am currently porting an application from MFC to MC++ but decided 
to
> reimplement the rendering (using GDI/GDI+ with WTL).
> 
> I am using VS.NET 2003 Final Beta. For reasons, I cannot tell, 
whenever,
> I exit the application, it continues to exist in memory. I debugged 
and
> found
> out that the application is locked in the Run() method 
::GetMessage() line.
> I then decided to use PostQuitMessage(0) in the WM_CLOSE handler 
and
> everything works normal.
> 
> The main application uses 4 normal DLLs developed with ATL/WTL.
> 
> Any idea as to what is going wrong?
> 
> Best regards,
> Paul.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Selormey | 4 Jan 2003 16:38

Re: Re: Exiting Application

Hello,

> if we assume that the problem hasn't got anything to do with the
> compiler you are using, it must be something in the code
>
> by default (in WTL) PostQuitMessage is sent from the mainframe's
> WM_DESTROY handler. What are you doing in your WM_DESTROY?

Just cleaning up. Thanks for the tip. I will examine it from here. May be
simply
set the bHandled to false.

Best regards,
Paul.

>
>
> --- In wtl@..., "Paul Selormey" <paul <at> t...> wrote:
> > Hello All,
> > I am currently porting an application from MFC to MC++ but decided
> to
> > reimplement the rendering (using GDI/GDI+ with WTL).
> >
> > I am using VS.NET 2003 Final Beta. For reasons, I cannot tell,
> whenever,
> > I exit the application, it continues to exist in memory. I debugged
> and
> > found
> > out that the application is locked in the Run() method
> ::GetMessage() line.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Lawroff | 5 Jan 2003 14:10
Picon

Where is VK_RETURN?

Hello there.

I try to make a ListView with subitem edit feature. I have a two classes:

class CLocalEdit : public CWindowImpl<CLocalEdit,CEdit>
{
public:
BEGIN_MSG_MAP(CLocalEdit)
MESSAGE_HANDLER(WM_CREATE,OnCreate)
MESSAGE_HANDLER(WM_KEYDOWN,OnKeyDown)
END_MSG_MAP()

LRESULT OnCreate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
bHandled=TRUE;
SetCapture();
SetFocus();
return DefWindowProc(uMsg,wParam,lParam);
};

LRESULT OnKeyDown(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
bHandled=TRUE;
if(wParam==VK_RETURN){
ReleaseCapture();
DestroyWindow();
return 0;
}
return DefWindowProc(uMsg,wParam,lParam);
};
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Barry | 5 Jan 2003 16:29
Favicon

Re: Where is VK_RETURN?

Nick Lawroff wrote:
> The Problem:
> When I press a enter key the WM_KEYDOWN message don't 
> sended into CLocalEdit message handler.
> But this key is catched in the owner dialog procedure. It's a strange.
> How i can catch a keydown message in the edit message procedure?

IsDialogMessage handles VK_RETURN keystrokes in order to implement the default push button. A dialog
control can override this by including DLGC_WANTALLKEYS in the value returned in response to
WM_GETDLGCODE. The edit controlalready does this if it has the ES_WANTRETURN style, but only if it also
has ES_MULTILINE. As you probably don't want to to use a multiline edit control, you can instead handle
WM_GETDLGCODE in your CLocalEdit class by returning DefWindowProc() | DLGC_WANTALLKEYS. The edit
control will then receiveWM_KEYDOWN when the return key is pressed. You'll want to catch VK_ESCAPE
keystrokes there too. For other keys, set bHandled to FALSE, otherwise the edit box navigation stops
working. The SetCapture thing is probably not a good idea. Instead, the edit control should dismiss
itself when it loses focus, i.e. when it receives WM_KILLFOCUS.

--

-- 
Jim Barry
MVP for Windows SDK
Permalink | Reply | 0 comments |

Gmane