Re: Difference WM_PAINT XP/CE

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

shouldn't the $@$#%@%$!!! remote-tools be able to connect through
Conmanclient2.exe ? my vs2005 debugconnection works, but not the tools.
I read that platformmanager (cemgrc.exe, not present in my OS-tree) is
obsolete. device manager component won't build in my platform (CoCreateguid
missing for some reason). what's up with this ? can I download it from
somewhere ? in that case I can try manual server. (fixing the device manager
build problem will probably take a lot of time, dont want to go into that now)

Kind regards,
Rob.










"Paul G. Tobey [eMVP]" wrote:

I have not observed *any* such effects in any of my applications, either for
distribution or for test locally, ever that I can recall. There might
easily be *some* difference in how the messages are processed, since
Windows, whether on desktop or embedded, makes no guarantee about what order
messages will be delivered, whether several WM_PAINT messages might be
combined into a single one, etc. However, there should not be any failure
to update a window when a portion of that window is uncovered, no. Also
remember that the code for desktop Windows is not the code for Windows CE.
They might roughly resemble each other, but Windows CE is not a port of
desktop Windows to other processors; it's a completely different OS that
happens to expose much of the same Win32 API as desktop Windows.

If it were me, I'd set aside the code I'm using, use the New Project wizard
in whatever IDE you're using, eVC, Visual Studio 2005, or Visual Studio
2008, and try to create a dead simple project that demonstrates the problem.
That's something that we in the community or Microsoft themselves could
actually use to verify the error or determine what is going on. If you
can't make it happen, you can look at your failing code more closely and
form a hypothesis about what might be causing the problem and then test that
(and repeat). If you can get the simple application to fail, you can post
that code here and maybe someone will try it on their Windows CE-based
device and see if it happens there, which would localize the problem or tell
you that you need to start a support incident with MS to try and get it
fixed.

You should also note that you haven't told us much about the target device,
the target operating system, etc. We don't know, for example, if you're
talking about CE 3, 4.x, 5.0, or 6.0 or even Windows Mobile. If you're
building the OS, we don't know what set of pieces of the operating system
you're including or what pieces you might not be including. We don't know
what display adapter or display driver for that adapter is in use.

Paul T.

"Rob" <__rob_AT_robtso_DOT_nl__> wrote in message
news:12B03909-52E9-4625-B55B-8D4D2681A2E6@xxxxxxxxxxxxxxxx
Hi,
The application hardly uses any messages for custom things.
So only the regular windows things that cause messages will occur.
Mostly focus/mouse/paint and that sort of things.
The behaviour with the missing wm-paint is very consistent, so I don't
think
it's load-related, although I'm not 100% sure yet. I think this is really
a
differrence in behaviour between XP/CE. Judging from your reaction I get
the
impression the shouldn't be such a differrence, right ? Since GDI is quite
standard, I would not expect it either, but unfortunately thats what I
observe. Since I have no clear indication that this is a know issue, I'll
have to dig further I guess...
I'll start with the spy tool and see if that shows me anything.

Kind regards,
Rob
www.robtso.nl





"Paul G. Tobey [eMVP]" wrote:

When you call GetMessage(), there are various orderings of several types
of
messages that, I suppose, could cause you to do the wrong thing. Paint
messages are not just dropped into the same queue as, say, WM_QUIT
messages;
there's a separate queue for paint requests. The paint queue has a
fairly
low 'priority' (higher than timer messages, but not much else). Maybe
you
are constantly posting messages of other types to your window's queue
and,
although the paint is there, it's never getting dispatched or something.
It
shouldn't permanently prevent WM_PAINT from being dispatched unless your
code is just not written correctly and constantly floods the application
with messages, I don't think.

Paul T.

"Rob" <__rob_AT_robtso_DOT_nl__> wrote in message
news:F7EB5E92-51AC-48E6-8472-87844B703972@xxxxxxxxxxxxxxxx
Hi,
Thanks for the response.
The FALSE is a typo I think, I'm sure I have the call as it should be.

I'll try the spy tool, but I'm pretty sure WM_PAINT is not sent.

In the help it says something about WM_PAINT not beeing sent if there's
any
other msg in the buffer. So maybe that means that if the CE-target is
very
busy and can't empty it's buffer, WM_PAINTS are missed ?

Kind regards,
Rob
www.robtso.nl







"Paul G. Tobey [eMVP]" wrote:

That's not a valid way to make the call, but in any case, I have no
problem
with calls of the form:

ShowWindow( hwnd, SW_HIDE );

which is the correct way to make the call. My guess would be that
there's
something different or non-standard about either how or where you are
making
the call (in response to a particular event, for example), or how the
message loop or window procedure for the underlying window is handling
what
happens. You could capture this sort of thing using Remote Spy++ and
just
see what messages are passed when you do the hide, both to the
underlying
window and to the window being hidden, too.

Paul T.

"Rob" <__rob_AT_robtso_DOT_nl__> wrote in message
news:F5FF84AE-E6DB-4D06-BFF9-B7D961817E56@xxxxxxxxxxxxxxxx
Hi,
In my application I see a differrent behaviour regarding WM_PAINT
for
CE
and
XP.
I have popupwindows that are basically normal windows.
Under XP, When a popup-window is removed (using
ShowWindow(hwnd,FALSE); )
the underlying window receives a WM_PAINT message with the rect set
to
the
popup area. This is as expected.
Under CE however, there is no WM_PAINT received, causing the area
not
to
be
repainted.

Is this known behaviour ?
Is there a standard solution for this ?

Kind Regards,
Rob.
www.robtso.nl


















.

Relevant Pages

  • RE: Problems Printing After XP Upgrade from 98SE
    ... following steps to clean the printer subsystem completely on the ... Windows NT Fax Monitor ... AppleTalk Printing Devices ... | workstation, but if I do that, I'll have to create the queue and re-share ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: as400 print que on windows 2003
    ... If the firewall doesn't fix your problem, try using RPM Select from ... The culprit may be the Windows Firewall. ... configuring TCP print services on another device (you can use Windows ... and the printer queue name exsists with no special characters. ...
    (comp.sys.ibm.as400.misc)
  • Re: Delaying events for fixed amounts of time.
    ... amount of time after the *FIRST* event with a given key arrives. ... I have anything Windows has to offer. ... Pause for, say, 250ms each time through the loop ... Have a queue of keys, each time a new key arrives, add it to the end ...
    (comp.programming.threads)
  • RE: Problems Printing After XP Upgrade from 98SE
    ... Can you print any local print jobs correctly in the system which ... Does the issue occur on only one Windows XP client or all other Windows ... | all of the jobs from the queue and print a test page from XP, ... |> Use the net.exe command to establish a persistent connection. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: How does PeekMessage really work?
    ... It's a good idea to analyze messages in WndProc or have a hook, ... message when it's already retrieved from the send-message queue because if I ... the right place to do this is inside the WinProc itself. ... Windows must somehow know of the origin, ...
    (microsoft.public.vc.mfc)