headers
avewtl | 1 Jun 2011 10:17
Picon
Favicon

How to get notified of mouse/keyboard activity without a global hook?

I have a transparent window (WS_EX_TRANSPARENT) floating topmost. 

Whenever there is a mouse move (anywhere on the screen) or keyboard stroke, it needs to display the related
info (e.g. mouse position).

Is it possible to capture mouse/keyboard activities without using a global hook? Anti-virus software
almost always triggers false alarms for the use of global hooks.

Any idea greatly appreciated.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
    (Yahoo! ID required)

<*> To change settings via email:
    wtl-digest@... 
    wtl-fullfeatured@...

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

Permalink | Reply | 0 comments |
headers
Bill | 2 Jun 2011 00:11
Favicon

Array of custom controls

I need to make an dynamic array of custom controls subclassed from CStatic in a dialog.   I have tried using
CAtlArray but after the controls are created and the dialog begins running, there is an exception in
CWindowImplBaseT::WindowProc.   If I create the array using CStatic controls, it works.

I am sure this has something to do with the copy semantics of CAtlArray and the custom controls but I don't
know what it is.  

Is my approach sound?

The control is actually Bjarke Vikoe's CColoredEditCtrl
http://www.viksoe.dk/code/coloredcontrols.htm

In the header file:

CAtlArray<CColoredEditCtrl> m_timestamps;

In OnInitDialog()

      for ( int i = 0; i < m_numTimestamps; i++ )
      {
         int ndx = m_timestamps.Add();

         m_timestamps[ndx].Create( m_hWnd, &timestampRect, 0,
            WS_CHILD | WS_VISIBLE | SS_CENTER );
         m_timestamps[ndx].ShowWindow(SW_SHOW);

         timestampRect.OffsetRect( 2 * controlWidth, 0 );
      }

------------------------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Igor Tandetnik | 2 Jun 2011 00:17
Favicon

Re: Array of custom controls

On 6/1/2011 6:11 PM, Bill wrote:
> I need to make an dynamic array of custom controls subclassed from
> CStatic in a dialog.   I have tried using CAtlArray but after the
> controls are created and the dialog begins running, there is an
> exception in CWindowImplBaseT::WindowProc.   If I create the array
> using CStatic controls, it works.

CAtlArray wants its elements to be copyable. CStatic is not derived from 
CWindowImpl, just from CWindow, and thus is copyable. Your class is 
derived from CWindowImpl, and thus is not copyable. So you can't put it 
into CAtlArray by value.

Allocate them on the heap, store pointers in CAtlArray.--
Igor Tandetnik

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
    (Yahoo! ID required)

<*> To change settings via email:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bill | 2 Jun 2011 01:48
Favicon

Re: Array of custom controls

What makes CWindowImpl not copyable?  The thunking that goes on?

--- In wtl@..., Igor Tandetnik <itandetnik <at> ...> wrote:
>
> On 6/1/2011 6:11 PM, Bill wrote:
> > I need to make an dynamic array of custom controls subclassed from
> > CStatic in a dialog.   I have tried using CAtlArray but after the
> > controls are created and the dialog begins running, there is an
> > exception in CWindowImplBaseT::WindowProc.   If I create the array
> > using CStatic controls, it works.
> 
> CAtlArray wants its elements to be copyable. CStatic is not derived from 
> CWindowImpl, just from CWindow, and thus is copyable. Your class is 
> derived from CWindowImpl, and thus is not copyable. So you can't put it 
> into CAtlArray by value.
> 
> Allocate them on the heap, store pointers in CAtlArray.--
> Igor Tandetnik
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 2 comments |
headers
Igor Tandetnik | 2 Jun 2011 02:26
Favicon

Re: Array of custom controls

On 6/1/2011 7:48 PM, Bill wrote:
> What makes CWindowImpl not copyable?  The thunking that goes on?

Yes. The object must stay alive for as long as the corresponding HWND is 
alive and receiving messages. It just doesn't make sense to copy 
CWindowImpl - the HWND only "knows" about one of them.
-- 
Igor Tandetnik

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
    (Yahoo! ID required)

<*> To change settings via email:
    wtl-digest@... 
    wtl-fullfeatured@...

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

Permalink | Reply | 1 comment |
headers
Michael Stephenson | 2 Jun 2011 03:52
Picon

RE: Re: Array of custom controls

I don’t think that the problem in this specific case is one of copying, rather it’s one of construction.  

When you call CAtlArray::Add() (the no-parameter version), it simply allocates memory for a new element. 
It does not actually construct the element.  It basically calls SetCount() to grow the array and returns
the new item count.

So, what you could do is call CAtlArray::SetCount() yourself to allocate memory for as many elements as you
need, and then call CAtlArray::CallConstructors() to actually construct each of the items in place
before you attempt to use the items.  I think this would work.

If you do create heap objects and just store the pointers in the array, you need to remember to call delete on
those pointers when you’re done with them; emptying the array won’t do that for you, it will just
deallocate the pointers.  If you are able to create them in-place as described above, I think you would need
to call CAtlArray::CallDestructors() when you’re done with the array.  So, either way you have to do
some cleanup.

I’m not sure if there isn’t a traits class other than CElementTraits that provides specialization for
pointers; I usually just end up deleting the objects the pointers point to when I’m done with the object.

From: wtl@...
[mailto:wtl@...] On Behalf Of Igor Tandetnik
Sent: Wednesday, June 01, 2011 8:27 PM
To: wtl@...
Subject: [wtl] Re: Array of custom controls

On 6/1/2011 7:48 PM, Bill wrote:
> What makes CWindowImpl not copyable? The thunking that goes on?

Yes. The object must stay alive for as long as the corresponding HWND is 
alive and receiving messages. It just doesn't make sense to copy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Stephenson | 2 Jun 2011 03:59
Picon

RE: Re: Array of custom controls

I should point out that if you are able to construct the static controls in place, you should never change the
size of the array after an initial SetCount; otherwise the array may reallocate/move it’s data buffer,
causing the same problem as you already have.

It’s probably cleaner to just allocate them with new and put pointers into the array (that’s what
I’ve always done).

From: Michael Stephenson [mailto:domehead100@...] 
Sent: Wednesday, June 01, 2011 9:53 PM
To: wtl@...
Subject: RE: [wtl] Re: Array of custom controls

I don’t think that the problem in this specific case is one of copying, rather it’s one of construction.  

When you call CAtlArray::Add() (the no-parameter version), it simply allocates memory for a new element. 
It does not actually construct the element.  It basically calls SetCount() to grow the array and returns
the new item count.

So, what you could do is call CAtlArray::SetCount() yourself to allocate memory for as many elements as you
need, and then call CAtlArray::CallConstructors() to actually construct each of the items in place
before you attempt to use the items.  I think this would work.

If you do create heap objects and just store the pointers in the array, you need to remember to call delete on
those pointers when you’re done with them; emptying the array won’t do that for you, it will just
deallocate the pointers.  If you are able to create them in-place as described above, I think you would need
to call CAtlArray::CallDestructors() when you’re done with the array.  So, either way you have to do
some cleanup.

I’m not sure if there isn’t a traits class other than CElementTraits that provides specialization for
pointers; I usually just end up deleting the objects the pointers point to when I’m done with the object.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philipp Kursawe | 5 Jun 2011 17:17
Picon
Gravatar

Re: Re: Array of custom controls

On Thu, Jun 2, 2011 at 3:59 AM, Michael Stephenson
<domehead100@...> wrote:
> I should point out that if you are able to construct the static controls in place, you should never change
the size of the array after an initial SetCount; otherwise the array may reallocate/move it’s data
buffer, causing the same problem as you already have.
>
>
>
> It’s probably cleaner to just allocate them with new and put pointers into the array (that’s what
I’ve always done).

But don't forget, that you would have to cleanup the array yourself
upon destruction ;)

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
    (Yahoo! ID required)

<*> To change settings via email:
    wtl-digest@...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill | 5 Jun 2011 19:42
Favicon

Re: Array of custom controls

Got it working with dynamically allocated controls.  And, yes, I am de-allocating them.  ;)

Thanks everybody.
Bill

--- In wtl@..., Philipp Kursawe <phil.kursawe <at> ...> wrote:
>
> On Thu, Jun 2, 2011 at 3:59 AM, Michael Stephenson
> <domehead100 <at> ...> wrote:
> > I should point out that if you are able to construct the static controls in place, you should never change
the size of the array after an initial SetCount; otherwise the array may reallocate/move it’s data
buffer, causing the same problem as you already have.
> >
> >
> >
> > It’s probably cleaner to just allocate them with new and put pointers into the array (that’s
what I’ve always done).
> 
> But don't forget, that you would have to cleanup the array yourself
> upon destruction ;)
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard B. | 8 Jun 2011 21:42
Picon
Favicon

WTL AppWizards don't UIUpdateChildWindows(); line to CMainDlg::OnIdle()...

I've been going through Michael Dunn's WTL for MFC tutorial from 
CodeProject, and in Part V it mentions that there is a bug where 
AppWizard doesn't add this line, so you have to manually add it.

I suppose it might not be considered a bug in that you may want a 
modeless dialog without UI idle-time updating, but why would you choose 
a modeless dialog without wanting UI updating ?

The fix is easy as it's just a matter of adding the line 
UIUpdateChildWindows(); to OnIdle() in 
wtl\Wizards\AppWiz\Files\Templates\1033\MainDlg.cpp , but I'm not sure 
how to submit this change so it's committed to the trunk ?

What are people's thoughts on changing this ?

Best Regards,
Richard B.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
(Continue reading)

Permalink | Reply | 4 comments |

Gmane