( 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
Yorick Hardy a écrit :
> This patch adds the audio driver winenbsd using the native NetBSD
> audio system as an alternative to OSS. On the one hand
> this is useful to directly make use of the features of the NetBSD
> audio system instead of using emulation, on the other hand
> it is another driver to maintain and is quite close to the wineoss driver.
> If the driver is accepted, I think the NetBSD support for wineoss
> should remain for testing and for the main driver.
I really think we're starting to create a real mess for the audio
drivers. It's always useful to have drivers access the HW at the lowest
level, so we should support NetBSD.
However, if the iface is rather close to OSS, I'd rather suggest we try
to integrate all the drivers with the same features into a single piece
of driver
> diff -urN /home/yorick/software/wine/wine/dlls/Makefile.in ./dlls/Makefile.in
> --- /home/yorick/software/wine/wine/dlls/Makefile.in Sat Feb 14 19:20:00 2004
> +++ ./dlls/Makefile.in Sat Feb 21 23:43:35 2004
> @@ -1745,6 +1749,7 @@
> winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack
> msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3
> winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas
> +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd
***
this should be winenbsd
A+
Hi,
I spent some time cross compiling all of Wine with MinGW according
to this recipe:
http://winehq.com/?issue=123#Cross-compiling Wine
and I thought you might be interested in the results. I can report
a bug in Wine's makefiles right away: having those vxd's in subdirectories
that end in .vxd causes make to barf on targets like this one:
ifsmgr.vxd$(DLLEXT): ifsmgr.vxd/ifsmgr.vxd$(DLLEXT)
$(RM) $@ && $(LN_S) ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $@
because, if $(DLLEXT) is empty, it will try to create a link
with a name that's already there as a directory.
Of all dlls these don't compile:
x11drv
kernel32
gdi32
ws2_32
comctl32
icmp
iphlapi
msvcrt
ntdll
rpcrt4
shlwapi
vnb.vxd
wininet
wsock32
x11drv, kernel32, gdi32 and ntdll being predictable, because they build
directly on X11 and Unix API's. Same goes for the networking related dlls
(ws2_32, icmp and iphlpapi, vnb.vxd, wininet, wsock32). msvcrt is close
to building because what I saw was mostly header clashes, which could be
fixed with proper guards I think.
rpcrt4 fails because it uses one Unix API, gettimeofday, and both comctl32
and shlwapi suffer from the bug in dlltool that Dmitry reported and fixed
recently.
-Hans
Christian Costa wrote:
>
> Hi,
>
> This patch adds implementation for the IFilterMapper interface.
Nice. I have few comments (see below).
> However filters registered with this interface require some work in
> devenum to
> be seen from application. This will be done when time permits.
Ok. I had assumed devenum was complete, but obviously not. Does it spit out
any fixme's?
...
> @@ -879,7 +893,7 @@
> if (SUCCEEDED(hrSub))
> hrSub =
> ICreateDevEnum_CreateClassEnumerator(pCreateDevEnum, &clsidCat,
> &pEnum, 0);
>
> - if (SUCCEEDED(hrSub))
> + if (SUCCEEDED(hrSub) && (hrSub == S_OK))
You can remove the SUCCEEDED(hrSub) completely here.
...
> + if (SUCCEEDED(hrSub))
> + {
> + len = (strlenW((WCHAR*)&V_UNION(&var, bstrVal))+1) *
> sizeof(WCHAR);
> + if (!(regfilters[idx].Name = CoTaskMemAlloc(len*2)))
> + hr = E_OUTOFMEMORY;
> + }
> +
> + if (SUCCEEDED(hrSub))
> + {
> + memcpy(regfilters[idx].Name, &V_UNION(&var, bstrVal), len);
> + regfilters[idx].Clsid = clsid;
> + idx++;
> + }
Indentation messed up a bit here and many other places.
...
> + if (cFetched > 0)
> + {
> + for(i = 0; i < cFetched; i++) {
> + /* The string in the REGFILTER structure must be
> allocated in the same block as the REGFILTER structure itself */
> + ppRegFilter[i] =
> (REGFILTER*)CoTaskMemAlloc(sizeof(REGFILTER)+(strlenW(This->RegFil
> ters[i].Name)+1)*sizeof(WCHAR));
> + if (!ppRegFilter[i]) {
> + while(i) {
> + CoTaskMemFree(ppRegFilter[--i]);
> + ppRegFilter[i] = NULL;
> + }
> + return E_OUTOFMEMORY;
> + }
> + ppRegFilter[i]->Clsid = This->RegFilters[i].Clsid;
> + ppRegFilter[i]->Name =
> (WCHAR*)((char*)ppRegFilter[i]+sizeof(REGFILTER));
> + CopyMemory(ppRegFilter[i]->Name,
> This->RegFilters[i].Name,
> (strlenW(This->RegFilters[i].Name)+1)*sizeof(WCHAR));
> + }
Please choose one style of bracket placement and stick to it (this occurs in
a few places too).
Other than these things, it looks fine.
Rob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I've been trying to use the free Borland C++ 5.5 command-line tools to compile
some Windows applications for my school assignments. To be specific, I am in
a graphics class where every turnin has to be Windows. :-(
Anyways, Borland C++ runs fine until it tries to link the program in question,
at which point ilink32.exe just sits there and eats CPU cycles. I've tried
letting it run in case it was simply slower than normal due to the Wine
layer, but that doesn't seem to be case (I've let it sit for minutes at a
time).
This occurs no matter how I run it (with wine or either of wineconsole's two
modes).
I was wondering if there is a way I can help figure out what the problem is so
that we can get this bug fixed.
Obligatory specs:
OS: Gentoo w/ Linux 2.6.3 (Wine was not compiled using NPTL, but OpenGL
support is in)
ATI OpenGL drivers
XFree86 4.3
GCC 3.3.1
Using fake_windows support
Please CC: any replies to me, as I am not subscribed to this list. Also, let
me know if there is any other information which would be useful.
Regards,
- Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAQVAQqjQYp5Omm0oRAofOAKDEhWcFavrlg/3VdjMOcx90hF/iiwCgvWUj
IS/FYImIKOxThQRj89LvwYc=
=+Gxw
-----END PGP SIGNATURE-----
Hi,
I can't compile authors.c due to some encoding issue with sed. I can
generate the authors.c file fine on the command line, but the same
command in the Makefile won't generate compilable code due to it
terminating the string constant before a UTF-8 character.
I am using Fedora Core 1 with latest updates.
$ sed --version
GNU sed version 4.0.8
Rob
Example of errors:
authors.c:19: error: stray '\366' in program
authors.c:20: error: `m' undeclared here (not in a function)
authors.c:20: error: initializer element is not constant
authors.c:20: error: (near initialization for `SHELL_Authors[18]')
authors.c:20: error: syntax error before string constant
Sibelius is an app for scoring music.
Sibelius 1 runs fine with wine. Sibelius 2 crashes on startup.
When it crashes there is no useful message, only "Unhandled exception". Using winedbg
I have found that Sibelius appears to be following a NULL pointer. I haven't yet
managed to track down where it's getting the bad pointer from... any suggestions would
be appreciated.
I've got some time and energy to try to make this work, but first...
Has anyone else worked or is some else currently working on this? What did you find?
How far did you get?
--
Andrew L. Bereson bereson(a)sea-ware.com (800)307-5754
To avoid problems like this one that recently appeared in the newsgroup
> Wine emulates XP which is good,
> however upon attempting installation it springs up a message requiring
> that i have my pc install SP1
it may be a good idea to set the winxp emulation to return the values of winxp sp1.
Ivan.
Christian Costa wrote:
> Hi,
>
> This time wih Rob's suggestions.
>
> Bye.
>
> Changelog :
> Implemented IFilterMapper and IEnumRegFilters interfaces.
> Fixed IFilterMapper2_EnumMatchingFilters.
>
> Christian Costa titan.costa(a)wanadoo.fr
>
Hi Christian,
Should I add you as a worker on quartz?
Tom
Matt Jaggard wrote:
>
> hi, I left a message, a longgg time ago on your website,
> I was wondering if you could please delete mjaggard(a)blueyonder.co.uk
> <mailto:[email protected]>. As I do not want spammers picking my
> address up. Thanks,
> The URL my address is on is called.
> http://www.winehq.org/hypermail/wine-users/2000/12/0438.html. if you
> could delete references to mjaggard(a)blueyonder.co.uk
> <mailto:[email protected]> or the page that would be brill
>
> Many Thanks
>
> M Jaggard
This is a joke or what?
Now you real addy with out the ( _ ) in it is on wine-devel not only by
your post but with my reply as well... Your odds of being spammed
have just increased by some 200% ... But don't worry spam is really
good for you..... :) My dear sweet Grandma use to keep us nice and fat
on it
when we were just little tikes..
Tom