Hello,
recently i tried to install some application and it hung when i
tried to select options.
It uses listbox with ownerdraw items with checkboxes. When listbox
is initially painted everything is ok. But when i try to select other
item, an extra WM_PAINT is sent to listbox when application draws item.
This causes infinite recursion.
I've been implemented a simple workaround adding boolean to listbox
structure but i have doubts. I briefly looked at some other controls
and had not noticed similar countermeasures.
Have somebody ever seen such behaviour?
It would be interesting to test other controls sending WM_PAINT from
ownerdraw handler but i'm short of time to do it soon.
Should this workaround implemented in this way or something
is wrong deeper with WM_PAINT handling?
Thanks.
Hello,
I am getting the attached error when running an install of Overnet v0.52.
Basically it cannot find NdrGetUserMarshalInfo(), despite it being in
the dll at entry point: 77d43452h, order 199. Any ideas what this
problem could be? I'm expecting this to be the symptom of some wider
problem.
Any help appreciated.
Kind regards
JG
p.s. Is there any way to get these mangled function names to be
displayed un-mangled please?
c:\opt\overnet_0_52>overnet
c:\opt\overnet_0_52>err:module:import_dll No implementation for
MSVCRT.dll.??_U@YAPAXI@Z imported from
L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef
err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z
imported from L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef
--
Homepage: http://jguk.org/
Blog: http://jguk.org/index.html#blog
Radio: http://jguk.org/index.html#radio
Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom
is a hang with the CPU at 100%, and it happens immediately if you try to
click on a notes 'bookmark', or shortly after you try to do much of
anything else if you try to avoid the 'bookmarks'.
Sorry that it took me so long to report this, when I decided that it wasn't
just a temporary instability I eventually had to iteratively compile (many)
CVS snapshots to narrow down when the problem was introduced because I
found it impossible to untangle the various patches that went in around
that time frame. I also ran afoul of the jack problems near the end.
I do not know how to narrow the problem down further. I tried running
winedbg (at CVS level a couple of days ago), and that seems to be broken
too -- it wanted to run things from the wine build tree? There are no
unusual console messages or anything when the problem happens.
Thanks,
Paul
z/OS core components development
Internet: prs(a)us.ibm.com
The Windows api method uses the function call IDvdInfo2::GetDiscID
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c…
This returns a unique 64bit ID for a DVD.
Has anyone found out what exactly it does to create this 64bit ID.
It would be nice to get linux DVD players to be able to use the same method.
Cheers
James
Ulrich Czekalla wrote:
>Running some tests under WinXP I noticed that if the edit control doesn't
>have WS_EX_CLIENTEDGE it looses the WS_BORDER style and it handles painting
>the border. This also has the side effect that it's non-client area goes to
>zero.
>
>ChangeLog:
> Ulrich Czekalla <ulrich(a)codeweavers.com>
> Handle painting the border if WS_EX_CLIENTEDGE is not set
>
>
This changelog doesn't really seem to match the patch. Are you sure it's
right?
>------------------------------------------------------------------------
>
>Index: dlls/user/edit.c
>===================================================================
>RCS file: /home/wine/wine/dlls/user/edit.c,v
>retrieving revision 1.2
>diff -u -r1.2 edit.c
>--- dlls/user/edit.c 9 Sep 2004 19:18:40 -0000 1.2
>+++ dlls/user/edit.c 15 Sep 2004 16:30:50 -0000
>@@ -4423,13 +4423,18 @@
> /*
> * In Win95 look and feel, the WS_BORDER style is replaced by the
> * WS_EX_CLIENTEDGE style for the edit control. This gives the edit
>- * control a non client area. Not always. This coordinates in some
>- * way with the window creation code in dialog.c When making
>- * modifications please ensure that the code still works for edit
>- * controls created directly with style 0x50800000, exStyle 0 (
>- * which should have a single pixel border)
>+ * control a nonclient area so we don't need to draw the border.
>+ * If WS_BORDER without WS_EX_CLIENTEDGE is specified we shouldn't have
>+ * a nonclient area and we should handle painting the border ourselves.
>+ *
>+ * When making modifications please ensure that the code still works
>+ * for edit controls created directly with style 0x50800000, exStyle 0
>+ * (which should have a single pixel border)
> */
>- es->style &= ~WS_BORDER;
>+ if (lpcs->dwExStyle & WS_EX_CLIENTEDGE)
>+ es->style &= ~WS_BORDER;
>+ else if (es->style & WS_BORDER)
>+ SetWindowLongW(hwnd, GWL_STYLE, es->style & ~WS_BORDER);
>
>
This doesn't seem right at all. The new code should be exactly the same
as the old, barring any side effects from SetWindowLong (which shouldn't
affect the control anyway since this the function changed is the handler
for WM_NCCREATE).
Rob
( I have posted a similiar question in wine-users,
don't flame me for doing so, just thinking about this
some more, perhaps it may be more a developer question
)
Ok, I have a windows app, that runs under wine fine -
not quite. This app has a form, with many text field
edit boxes on. Quite often these edit boxes already
have text values, ie. they are not empty - there is a
database behind the form.
Anyway, the form shows on the screen, but the text
within the edit fields is invisible, until you
activate each edit box component. When you leave one
edit box to the next, the text remains visible.
It seems like the repainting is not working, on
initial startup of the form.
As a way to debug this database app ( I don't have the
source code for it ) I wrote a real basic form app in
Visual Studio, with two edit boxes, with data in each.
Now this basic app shows the text values immediately
on startup. So there must be something different that
the database app is not doing.
I then ran wine using 'wine --debugmsg +edit
programname' for both app's.
I see both logging 'Creating ANSI edit control, style
= xxxxx'
but the style reference is different between apps - I
am not sure if this the cause or not.
The problem app reports style = 54011104 and the basic
app shows style = 50010080.
Can somebody explain what this style reference means
and how do I force an app to use a certain style of
edit box ?
What other wine class debugmsg types should I use to
narrow down the source of this problem ?
Is there anyway I can check to see how the database
app is repainting text within the text edit components
?
Regards
Doug Herbert.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
> Btw, does wine ever _use_ PTRACE_SINGLESTEP for any of the things it does?
>
> If it does, then that woulc certainly explain why my "fix" made no
> difference: my fix _only_ handles the case where the ptracer never
> actually asks for single-stepping, and single-stepping was started
> entirely by the program being run (ie by setting TF in eflags from within
> the program itself).
>
> But if wine ends up using PTRACE_SINGESTEP because wine actually wants to
> single-step over some instructions, then the kernel will set the PT_DTRACE
> bit, and start tracing through signal handlers too. The way Wine doesn't
> want..
wine mixes both approches, we have (to control what's generated inside the
various exception) to ptrace from our NT-kernel-like process (the ptracer) to
get the context of the exception. Restart from the ptracer is done with
PTRACE_SINGLESTEP.
(BTW: I also CC:ed wine-devel ML, that might be of interest to them too)
A+
>>Well, apparently we don't use sched_yield, so the problem must
>>> lie somewhere else. Maybe Con can help us out here? Alexandre says he
>>> doesn't know what the issue is either and somebody needs to investigate. I
>>> guess we do need to concern ourselves over the details :)
>
>
> Interesting. Probably the most valuable information is that it seems to
> work fine if we artificially limit the threads to exactly the same
> timeslice _or_ we put them at such a low priority that they are forced
> to be guaranteed to round robin one task at a time. This is the way 2.4
> used to work which is why with the new 2.6 schedulers which do far more
> out-of-order rescheduling some applications have a problem; particularly
> under load. I suspect it's actually the latter issue. Locking between
> threads should prevent that being a problem, though. You already
> mentioned that you dont use sched_yield() and I couldn't even begin to
> look at the wine code myself so perhaps you know something more.
Hi Con,
One thought that occurred to me, and this is just a random theory, is
that maybe the issue is not with the Wine code but the Win32 code run on
top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows
(NT) scheduling? Could it be that some apps are written to expect
Windows-style scheduling and fail to work if they don't get it?
In case you hadn't noticed, I'm afraid I only have first-year CS
knowledge of scheduling :/
thanks -mike
I originally posted this to the -users list, but I was
contacted by Robbert Xerox, who had the exact same
issue, and thus far nobody has replyed in the users
list, so maybe it will get more attention here.
> Foobar2000 worked virtually perfectly in the
20041019
> release (aside from some comctrl32 repainting issues
> -- which native comctrl32.dll fixed), but in
20041201
> it is completely unuseable. Two major problems:
> 1) The toolbars are completely gone. They are
sort-of
> displayed when they get activity via mouse-press or
> whatever, but they do not repaint correctly at all.
> See this screenshot for details:
>
http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif
> 2) It takes 100% cpu. In the 20041021 release, it
> hovered around 5% cpu (on my athlon 64 3200+), which
> was excellent because that beat most native linux
> audio players.
> The console log is as follows (no errors or
warnings):
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub!
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub!
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,2)-stub!
> fixme:hook:NotifyWinEvent (32772,0x1002a,-4,0)-stub!
> fixme:hook:NotifyWinEvent (32772,0x1002c,-4,0)-stub!
> fixme:win:SetWindowTextA cannot set text "" of other
> process window (nil)
> Does anyone know what is going on here?
I have since found out that if you use a the builtin
comctrl32.dll, none of the window repaints at all. In
previous wine releases, using the builtin
comctrl32.dll would just create minor glitches (ex.
the status bar wouldn't update).
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Hello,
For the past week or so, building from cvs on a debian/stable system w/
alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks
on alsa-specific code in wine;
I attached the log; note that I did a `cvs update -dPA` and `make
distclean` so this can't be any problem with the source I have
Any ideas? Maybe you can point me to a place where I can read how to fix
this properly (I never worked on alsa-specific code before...) or
something like that
regards,
Joris
