View Single Post
  #12   Report Post  
Posted to microsoft.public.excel.programming,microsoft.public.office.developer.vba,microsoft.public.word.vba.general
Karl E. Peterson[_2_] Karl E. Peterson[_2_] is offline
external usenet poster
 
Posts: 6
Default Best Practice for Obtaining hWnd


Peter T wrote:
"Karl E. Peterson" wrote in message
So I can use it in normal VB6 code, and it'll only come into play if the
code is sucked into VBA?


Yes in the sense it doesn't exist in VB6, even with all the references to
VBA and object model.

#If VBA6 then
' this code module is being used in VBA
#Else
' this code module is in VB6 (but conceivably in say xl97)
#End if

IIRC this came up when discussing your SendKeys replacement.


Ahhh, right. I must burn this into my memory, because it's an incredibly useful way
to distinguish the slight differences in approach required between the two.

If there's any possibility a form with a similar caption could be showing
elsewhere, even in another instance, best to temporarily change the
caption
to something unique.


Yep. That's one of the reasons I tended against the FindWindow approach,
as well. But the GetActiveWindow approach is going to work pretty well, I
think.


Typically want to get the form's hWnd in the Initialize event, I assume the
only time GetActiveWindow could be reliably used is in the form's Activate
event?


No, it oughta work anytime the user is interacting. But, hmmm, yeah if the form
were non-modal, it could conceivably return one of the main application windows as
well. Probably best to stick with caching the value at first activation.

I'm curious though, what are the other reasons you tend against FindWindow,
even with a unique caption.


Assuming the unique caption is one strike, for sure. But you also have no
"future-proofing" if they happen to change the classname. Those would be the bigger
drawbacks. But neither is so large as to be deal killers.
--
..NET: It's About Trust!
http://vfred.mvps.org