( 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
Hi,
This is the first of two patches that will fix some problems on soundcards
using the i810 audio codec. The main probem with this soundcard is that it
only supports a frequency of 48kHz in 16bit stereo mode.
This first patch to dsound queries if the card supports 16bit and if so it
uses it, else it uses 8bit. Further it also detects if the card supports
stereo or not. The patch was inspired by one from transgaming to rewind but
that patch did a bit the opposite (defaulting to 8bit ..).
Roderick Colenbrander
G'day all,
Due to restrictions in my current setup I'm not subscribed to wine-devel at the moment, please cc me.
This is a longstanding bug with Word97. It exists in Crossover office 2.1.0 as well and was reported
in the Codeweavers database months ago. It usually results in the "style" drop down box on the far
left of the toolbar blanking it's entries.
I have a pretty complex default template that has a number of styles in it that all render with
funky true-type fonts. When you scroll up and down this list a couple of times, wine ceases to
render the entries. It used to lock up in an endless loop somewhere, but now it bombs with the below
error message.
I compile from CVS a couple of times a week, and subject to time I'm happy to do anything at all to
assist in debugging this if it will help someone. (I have worked around it by creating tool bars
with all my styles on it so I don't have to use this box)
Regards,
Brad
fixme:hook:NotifyWinEvent (32773,0x30035,-4,11)-stub!
fixme:hook:NotifyWinEvent (32773,0x30035,-4,10)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,9)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,8)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,7)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,6)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,5)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,4)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (32773,0x30035,-4,3)-stub!
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
fixme:hook:NotifyWinEvent (5,0x10022,-3,0)-stub!
fixme:ole:I_RpcWindowProc (0x10026,0000001c,00000000,00000000): stub
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.
Hi everyone,
I've been following Wine development for a while but
now I think it's time to contribute something. I don't
use Windows anymore (except for PowerPoint at work),
but I decided it would be good to be able to play some
games on Linux. So I grabbed Wine from CVS, compiled it
up and tested some games, with the intention of finding
where the problems were and hopefully fixing them. I
have put my results on a web page at:
http://www.epcc.ed.ac.uk/~jamesp/wine-games.html
to avoid making this posting even longer. Note that I
haven't looked in detail at most of these yet, I just
tried them out once to see what would happen. I'm
gradually working through the list, debugging them.
I've already submitted one patch (to solve a D3D blend
mode problem that affected SonicR). I have traced a
number of the other problems to specific aspects of
Wine, but I'm not sure how to go about fixing them. Any
advice on these points from experienced developers
would be welcome:
1. MusicVR exits with this error:
X Error of failed request: GLXBadDrawable
Major opcode of failed request: 145 (GLX)
Minor opcode of failed request: 11 (X_GLXSwapBuffers)
Serial number of failed request: 10522
Current serial number in output stream: 10523
I traced it to the line:
glXMakeCurrent(default_display, None, NULL)
in dlls/opengl32/wgl.c. My OpenGL (nVidia) doesn't
seem to like the drawable being set to None, although
according to the GLX docs, this should be OK. Simply
commenting out the line makes the game work fine, but
I don't think this is the right fix. Any ideas?
2. Settlers III crashes almost straight away, in the
code of the PE-Crypt protection system. This is caused
by the processor's direction flag (which controls
whether pointers are incremented or decremented by
string instructions) getting reset somewhere, probably
in Wine code. Can anyone comment on treatment of this
flag in Wine? Is it likely to be clobbered in lots of
places? Basically, is there any hope of getting this
working? I'm not sure where to start with this one.
3. South Park Rally creates its DirectInput object
using the generic OLE functions, which doesn't work in
Wine right now. I have some initial code to support
this, but not sure if it does everything it needs to.
I have:
- copied regsvr.c from the DirectSound DLL and edited
it to register the DirectInput classes, and implement
the DirectInput Dll[Un]RegisterServer methods
- removed the stubs of those functions from dinput_main.c
- added regsvr.c to the list of source files in dinput's
Makefile.in, and added ole32 and advapi32 to the list of
imports
It would also be good if the default registry created
by winebuild contained the necessary entries to make
this work (I had to add them by hand), but I couldn't
find where the initial registry entries come from.
If this all sounds OK, I can submit it as a patch.
Although even with this support, South Park Rally fails
with another DirectX problem. One step at a time though...
4. The CD audio in Sonic 3D doesn't play in Wine yet. I
found there were two separate problems causing this.
First, it's trying to use CD device 2. No idea where
this number comes from, as I have only one CD-ROM in
the system, and the game doesn't seem to be specifying
device 2 anywhere. Anyone know where mcicda gets the
device ID from, save me spending ages looking for it?
Second, it's using TMSF (track,minutes,seconds,frames)
format to specify locations on the CD. These appear as
colon-separated values in the MCI commands
(e.g. "02:00:00") but the argument parser chokes on
them, expecting a single integer. I got around this by
hacking MCI_GetDWord to recognise the colons and parse
these arguments correctly, but maybe that's not the
way to do it... any suggestions?
Sorry this post is so long. Finally, I'd just like to
say great job everyone! I was impressed that things
like DirectX, InstallShield and even SecuROM copy
protection are working so well - they're flawless on
some of the games I tried. It's really come on since
I first tried it back in 2000.
Cheers,
James
I am having the following problem with a abnt2 (Brazilian) keyboard:
When the numlock is off both delete keys work correctly. If the numlock is on
both key produce a delete plus a comma. The message
http://www.winehq.org/hypermail/wine-patches/2002/12/0329.html
appears to describe the same problem. But the proposed patch didn't work for
me.
Attached is a xev log. The numlock is initially on. Them the I press the
middle keyboard delete, keypad delete, numlock, middle keyboard delete and
keypad delete.
Thanks for any help.
Rafael Ávila de Espíndola
Dear Wine Devel list,
I was reading the Drag&Drop implementation in the Wine sources and didn't find a SetProp() of the handle with the property "OleDropTargetInterface" to the IDropTarget pointer.
I think it's not a well documented property (not in MSDN) but it appears to be useful if somebody (sometime) will try to automate drag&drop operations.
Cheers,
Sebastian Wain
--
http://swain.webframe.org
Joel Konkle-Parker wrote:
> Is there such a thing as a source code visualization tool that makes a
> "map" of a program's source? Kind of like:
>
> main()
> |
> |
> function1()
> /\
> / \
> func2() func3()
> |
> |
> func4()
>
> I'm basically looking for something that will help me "see" how a
> program is laid out so that I can start working on it.
>
> Thanks in advance.
>
>
I was looking for a similar thing a while back. One great tool for
navigating the wine source is the etags program. In the wine source
directory, type 'make etags'. This makes a file called TAGS. Then, start
emacs, and type alt-x visit-tags-table, and load the tags file. You can
navigate the source by function. See the tags manpage and the emacs
manpage for the tags section for details.
Blake
`--------------- Forwarded message (end)