[shlwapi/tests/shreg.c] Question about ExpandEnvironmentStringsA
Hi, while going through some results on test.winehq.org I've noticed something regarding ExpandEnvironmentStringsA. One of the NT4 tests (I think it's one from Ivan Leo Puoti?) comes back with: shreg.c:97:sExplen1 = (24) shreg.c:99:sExplen2 = (86) while all others (i.e. win98/nt4/w2k/winxp) I've seen so far return: shreg.c:97:sExplen1 = (12) shreg.c:99:sExplen2 = (43) Why is/could the length be doubled in his case? Cheers, Paul.
Re: [ntdll] NtCreateFile update
Jonathan Wilson wrote: Does anyone have any links to these "documented only because Microsoft have to" type functions (like NtCreateFile etc)? Ever tried google? http://www.google.com/search?q=NtCreateFile&sourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8
Re: [ntdll] NtCreateFile update
I found that page. But what I want to know is if there is one overall list (at msdn or elsewhere) of all the things Microsoft has documented as a result of the various lawsuits in various places (US, EU etc). I didnt see anything specific on the MSDN link that pointed to such a thing.
Broken winetest compilation
Hi, Building winetests is broken again (see errors at end of email). Is this the usual mingw missing functions again? Cheers, Paul. PS, actually there's another problem to do with a RAID system dying. I'll relocate the webpages to somewhere a bit better. i686-mingw32msvc-gcc db.o record.o suminfo.o testlist.o -o msi_test.exe -lmsi -lkernel32 suminfo.o(.text+0x405): In function `func_suminfo': /home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:111: undefinedreference to [EMAIL PROTECTED]' suminfo.o(.text+0x473):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:114: undefined reference to [EMAIL PROTECTED]' suminfo.o(.text+0x4dc):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:117: undefined reference to [EMAIL PROTECTED]' suminfo.o(.text+0x545):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:120: undefined reference to [EMAIL PROTECTED]' suminfo.o(.text+0x637):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:130: undefined reference to [EMAIL PROTECTED]' suminfo.o(.text+0x69f):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:133: more undefined references to [EMAIL PROTECTED]' follow suminfo.o(.text+0xea6): In function `func_suminfo': /home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:197: undefinedreference to [EMAIL PROTECTED]' distcc[17612] ERROR: compile on localhost failed make: *** [msi_test.exe] Error 1 pgpNuphN5cVIw.pgp Description: PGP signature
Re: dlls/user/button.c - fix AUTO3STATE with BS_OWNERDRAW (Resend)
Michael Lin <[EMAIL PROTECTED]> writes:
> inline static UINT get_button_type( LONG window_style )
> {
> -return (window_style & 0x0f);
> +if ((window_style & BS_OWNERDRAW) == BS_OWNERDRAW)
> +return BS_OWNERDRAW;
> +else
> +return (window_style & 0x0f);
BS_OWNERDRAW is not a bit mask, this won't work right. What is the
problem you are trying to fix?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: RICHEDIT: RTF reader i18n (now with font charset support)
On Mon, 21 Mar 2005 14:40:38 +0300 Vitaly Lipatov <[EMAIL PROTECTED]> wrote: > > > Will we do this code in locale independent manner? Why we have > > > ansiCodePage=1252 by default? > > > > It is locale independent. 1252 is the default value used if RTF does not > > specify another codepage (which almost never happens). If I used > > GetACP() here, the same RTF document would be differently imported > > depending on user locale. RTF is not supposed to act like this. If RTF > If I try open RTF where codepage is not specified, guessed codepage must be > the same as ACP. For instance if I get such file here in Russia, I suppose it > in cp1251 codepage. > > > does not specify any codepage it means that it uses CP1252. > I recommend use GetACP, otherwise in will some disadvantage for non cp1252 > users. > > > How do you find this code is locale dependent? IMHO it's _in_dependent of > > locale. > I worry only about default codepage. OK, I've made some tests using the original M$ richedit, and they show the following: \ansicpg keyword in the RTF header does not affect the used encoding when importing RTF. The encoding used for import is determined by \fcharset setting for the "current" font. If it specifies \fcharset1 (DEFAULT_CHARSET) or is omitted, GetACP() is used. If it specifies \fcharset0 (ANSI_CHARSET), CP1252 is used regardless of current locale. For other charsets, their respective codepages are used. I'll commit the required changes to the RTF reader soon. -- Ph.
Re: [ntdll] NtCreateFile update
Jonathan Wilson wrote: I found that page. But what I want to know is if there is one overall list (at msdn or elsewhere) of all the things Microsoft has documented as a result of the various lawsuits in various places (US, EU etc). I didnt see anything specific on the MSDN link that pointed to such a thing. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/html/api-overview.asp Ivan.
Re: [shlwapi/tests/shreg.c] Question about ExpandEnvironmentStringsA
Paul Vriens wrote: Hi, while going through some results on test.winehq.org I've noticed something regarding ExpandEnvironmentStringsA. One of the NT4 tests (I think it's one from Ivan Leo Puoti?) Possibly, I don't use winrash because I want interactive tests, so you won't see my nick in the results. Ivan.
Re: Eliminate casts of the return value of HeapAlloc
On Mon, 21 Mar 2005, Alexandre Julliard wrote: [...] Log message: Mike McCormack <[EMAIL PROTECTED]> Eliminate casts of the return value of HeapAlloc. This could be turned into a pretty easy janitorial the starting point of which would be the output of this command: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" (344 lines) There are a couple of places where the output of HeapAlloc is being cast to a DWORD but except for those it seems pretty straightforward. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ La terre est une b\xEAta...
Re: [shlwapi/tests/shreg.c] Question about ExpandEnvironmentStringsA
On Mon, 2005-03-21 at 13:39, Ivan Leo Puoti wrote: > Paul Vriens wrote: > > Hi, > > > > while going through some results on test.winehq.org I've noticed > > something regarding ExpandEnvironmentStringsA. One of the NT4 tests (I > > think it's one from Ivan Leo Puoti?) > > Possibly, I don't use winrash because I want interactive tests, so you won't > see my nick in the results. I don't use winrash (anymore), but start winetest with the -t (tag) option to still have something. Paul.
Status and (nearby) future of wined3d
Hi, what will happen to the wined3d stuff, now Oliver has some 'problems' staying on-line? There were at least 4 patches or so he send which were not applied (yet). If the sole reason for that is that it couldn't be merged/applied to CVS I could give it a try. But that's about the only thing I can do regarding wined3d stuff. Cheers, Paul.
Re: Broken winetest compilation
On Monday 21 March 2005 12:49, Paul Millar wrote: > Building winetests is broken again (see errors at end of email). > Is this the usual mingw missing functions again? I updated my RPM packages today and included a fix for this breakage. As usual you can find them here: http://mirzam.it.vu.nl/mingw/ -Hans
Re: Preview-window works in Virtualdub,Paltalk etc.
That code doesn't with with my QuickCam 3000, which defaults to YUV420.
The attached patch adds YUV420 support back in to vidcat.c, and should
still work with RGB cams.
Rick
On Sun, 2005-03-20 at 22:37 +, luis lenders wrote:
> Hi, don't know if it's of much use for anyone, but i
> can now view the images from my webcam in the preview
> window in programs like Virtualdub, Paltalk and
> WebCamnow. Basically the attached "patch" reads a
> RGB-image from my
> video4linux device and "turns" this into a bitmap,
> which is then displayed. The device must be able to
> "read RGB's". In case you would like to try, replace
> dlls/avicap32 with the attached one, and replace
> include/vfw.h with the attached vfw.h. I'm skilled
> enough to turn this into a real patch, maybe someone
> with more programming capabilities could give it try.
>
> Regards Luis
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
--- vidcat.c 2005-03-20 23:07:42.0 -0500
+++ ../wine/dlls/avicap32/vidcat.c 2005-03-21 09:02:09.211495248 -0500
@@ -101,7 +101,9 @@
int len;
int bytes = 3;
-
+ if (ioctl (dev, VIDIOCGMBUF, &vid_buf) == -1) {
+ printf("we gonna use read\n");
+ }
//VIDIOCGMBUF reports the size of buffer to mmap and the offset within the buffer for each frame
if (ioctl (dev, VIDIOCGMBUF, &vid_buf) != -1)
{
@@ -138,21 +140,22 @@
}
*size = vid_buf.size;
-/* if (palette == VIDEO_PALETTE_YUV420P) {
- if (verbose)
- fprintf (stderr, "converting from YUV to RGB\n");
+ if (palette == VIDEO_PALETTE_YUV420P) {
+// if (verbose)
+// fprintf (stderr, "converting from YUV to RGB\n");
convmap = malloc ( width * height * bytes );
v4l_yuv420p2rgb (convmap, map, width, height, bytes * 8);
memcpy (map, convmap, (size_t) width * height * bytes);
free (convmap);
} else if (palette == VIDEO_PALETTE_YUV422P) {
- if (verbose)
- fprintf (stderr, "converting from YUV to RGB\n");
+// if (verbose)
+// fprintf (stderr, "converting from YUV to RGB\n");
convmap = malloc ( width * height * bytes );
v4l_yuv422p2rgb (convmap, map, width, height, bytes * 8);
memcpy (map, convmap, (size_t) width * height * bytes);
free (convmap);
- }*/
+ }
+
printf ("got picture\n");
return (map);
}
@@ -364,14 +367,33 @@
//int palette = VIDEO_PALETTE_YUV420;
int num = 0;
dev=DEVICE;
+
+ if (!num) {
+ /* if we loop we have to do this only once. so
+ * * check frame number and execute only for the
+ * * frame number "0".
+ **/
+ if (v4l_set_input (dev, input, norm) == -1) {
+ return (1);
+ }
+ if (v4l_check_size (dev, &width, &height) == -1) {
+ return (1);
+ }
+ if (v4l_check_palette (dev, &palette) == -1) {
+ return (1);
+ }
+ }
+
+
+
+
image = get_image (dev, width, height, palette, &size);
// if (!size)
// close (dev);
if (image) {
-
/*char* */bmpimage=ConvertRGBToBMPBuffer (image,width,height);//,newsize );
-
+
// SaveBMP (bmpimage,width,height, bmpsize, szName );
// if (size) {
Re: Status and (nearby) future of wined3d
--- Paul Vriens <[EMAIL PROTECTED]> wrote: > Hi, > > what will happen to the wined3d stuff, now Oliver > has some 'problems' > staying on-line? > Thanks to everyone I should be ok for a while, now. > > If the sole reason for that is that it couldn't be > merged/applied to CVS > I could give it a try. But that's about the only > thing I can do > regarding wined3d stuff. > I've just merged with wine head and am about to resend the patches, and another couple for stateblocks and sampler states. After that there's vertex declarations and resource tracking, pointsprites , non-power2 textures, memory management, D3DPOOL_DEFAULT texture operations and a few more tidyups. Then I should have all the stable work synced with winehead. After that stateblocks need to be refactored to get offscreen textures, swapchains and multiple devices/threads working properly which may take a while to stabalise. A software vertex pipeline also needs writing to fill in the gaps in the hardware support which is faily easy, and d3d8 interfaces need to wrap up wined3d. Shaders needs moving across from d3d8 which is faily simple and shader 2.0 support needs writing which is a little tricker. > Cheers, > > Paul. > > > Send instant messages to your online friends http://uk.messenger.yahoo.com
Regression in file tests
Between http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.46 http://test.winehq.org/data/200502231000/ and http://test.winehq.org/data/200503041000/ http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.48 we have more about 50 more failed test results. What happened? regards, Jakob
Re: [WINEALSA] direct sound fallback patch
Robert Reif wrote:
Don't fail when opening a device in direct sound mode.
Rather, try alternate formats first before failing.
With the wave api, requesting a format that the
hardware can't do should fail so the wave mapper can
fix it up. However, the direct sound api does not
expect a failure (within reason) if the format isn't
supported in hardware but expects the closest
format that the hardware does support.
This gets the direct sound regression tests working
better with the ALSA "hw" device and my lame Intel
builtin sound card.
Use this patch instead. Fixes a format bug.
Index: dlls/winmm/winealsa/audio.c
===
RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v
retrieving revision 1.71
diff -u -p -r1.71 audio.c
--- dlls/winmm/winealsa/audio.c 21 Mar 2005 12:32:48 - 1.71
+++ dlls/winmm/winealsa/audio.c 21 Mar 2005 18:02:05 -
@@ -315,6 +315,22 @@ static const char * getMessage(UINT msg)
return unknown;
}
+static const char * getFormat(WORD wFormatTag)
+{
+static char unknown[32];
+#define FMT_TO_STR(x) case x: return #x
+switch(wFormatTag) {
+FMT_TO_STR(WAVE_FORMAT_PCM);
+FMT_TO_STR(WAVE_FORMAT_EXTENSIBLE);
+FMT_TO_STR(WAVE_FORMAT_MULAW);
+FMT_TO_STR(WAVE_FORMAT_ALAW);
+FMT_TO_STR(WAVE_FORMAT_ADPCM);
+}
+#undef FMT_TO_STR
+sprintf(unknown, "UNKNOWN(0x%04x)", wFormatTag);
+return unknown;
+}
+
static DWORD bytes_to_mmtime(LPMMTIME lpTime, DWORD position,
WAVEFORMATPCMEX* format)
{
@@ -1758,6 +1774,12 @@ static DWORD wodOpen(WORD wDevID, LPWAVE
memcpy(&wwo->waveDesc, lpDesc, sizeof(WAVEOPENDESC));
copy_format(lpDesc->lpFormat, &wwo->format);
+TRACE("Requested this format: %ldx%dx%d %s\n",
+ wwo->format.Format.nSamplesPerSec,
+ wwo->format.Format.wBitsPerSample,
+ wwo->format.Format.nChannels,
+ getFormat(wwo->format.Format.wFormatTag));
+
if (wwo->format.Format.wBitsPerSample == 0) {
WARN("Resetting zeroed wBitsPerSample\n");
wwo->format.Format.wBitsPerSample = 8 *
@@ -1789,7 +1811,19 @@ static DWORD wodOpen(WORD wDevID, LPWAVE
else
wwo->write = snd_pcm_mmap_writei;
-EXIT_ON_ERROR( snd_pcm_hw_params_set_channels(pcm, hw_params,
wwo->format.Format.nChannels), MMSYSERR_INVALPARAM, "unable to set required
channels");
+if ((err = snd_pcm_hw_params_set_channels(pcm, hw_params,
wwo->format.Format.nChannels)) < 0) {
+WARN("unable to set required channels: %d\n",
wwo->format.Format.nChannels);
+if (dwFlags & WAVE_DIRECTSOUND) {
+if (wwo->format.Format.nChannels > 2)
+wwo->format.Format.nChannels = 2;
+else if (wwo->format.Format.nChannels == 2)
+wwo->format.Format.nChannels = 1;
+else if (wwo->format.Format.nChannels == 1)
+wwo->format.Format.nChannels = 2;
+WARN("changed number of channels from %d to %d\n",
lpDesc->lpFormat->nChannels, wwo->format.Format.nChannels);
+}
+EXIT_ON_ERROR( snd_pcm_hw_params_set_channels(pcm, hw_params,
wwo->format.Format.nChannels ), MMSYSERR_INVALPARAM, "unable to set required
channels" );
+}
if ((wwo->format.Format.wFormatTag == WAVE_FORMAT_PCM) ||
((wwo->format.Format.wFormatTag == WAVE_FORMAT_EXTENSIBLE) &&
@@ -1819,7 +1853,24 @@ static DWORD wodOpen(WORD wDevID, LPWAVE
return WAVERR_BADFORMAT;
}
-EXIT_ON_ERROR( snd_pcm_hw_params_set_format(pcm, hw_params, format),
MMSYSERR_INVALPARAM, "unable to set required format");
+if ((err = snd_pcm_hw_params_set_format(pcm, hw_params, format)) < 0) {
+WARN("unable to set required format: %s\n",
snd_pcm_format_name(format));
+if (dwFlags & WAVE_DIRECTSOUND) {
+if ((wwo->format.Format.wFormatTag == WAVE_FORMAT_PCM) ||
+ ((wwo->format.Format.wFormatTag == WAVE_FORMAT_EXTENSIBLE) &&
+ IsEqualGUID(&wwo->format.SubFormat,
&KSDATAFORMAT_SUBTYPE_PCM))) {
+if (wwo->format.Format.wBitsPerSample != 16) {
+wwo->format.Format.wBitsPerSample = 16;
+format = SND_PCM_FORMAT_S16_LE;
+} else {
+wwo->format.Format.wBitsPerSample = 8;
+format = SND_PCM_FORMAT_U8;
+}
+WARN("changed bits per sample from %d to %d\n",
lpDesc->lpFormat->wBitsPerSample, wwo->format.Format.wBitsPerSample);
+}
+}
+EXIT_ON_ERROR( snd_pcm_hw_params_set_format(pcm, hw_params, format),
MMSYSERR_INVALPARAM, "unable to set required format" );
+}
rate = wwo->format.Format.nSamplesPerSec;
dir=0;
@@ -1830,9 +1881,14 @@ static DWORD wodOpen(WORD wDevID, LPWAVE
return WAVERR_BADFORMAT;
}
if (rate != wwo->format.Format.nSamplesPerSec) {
- ERR("Rate doesn't match (requested %ld Hz, got %d Hz)\n",
ww
Re: [WINEALSA] multiple sound card support patch review needed
On Sat, 19 Mar 2005 14:44:30 -0500, Robert Reif <[EMAIL PROTECTED]> wrote: > I downloaded the program and ran it and don't even get as far as you got. > > Try different devices and combinations of devices: > hw, plug:hw plughw > and see if that helps. I'll look into it when I get some more time. Updated my tree. App works again. Can now also test the behaviour of this patch. When setting your PlaybackDevice to a dmix plug device you will get a list of (the same) dmix devices. This works arround it, but not really nicely I think: char *prev_name; if(strcmp(snd_pcm_info_get_name(info),prev_name)) prev_name = (char *)snd_pcm_info_get_name(info); else continue; And I think you should not break out of the detect loop when you can't open a device. There might be more devices you can use arround. Talking about this break: snd_pcm_open(&h, wwo->device, SND_PCM_STREAM_PLAYBACK, SND_PCM_NONBLOCK); if (!h) break; Changing this to a continue will make my second soundcard device show up if my first (no hardware mixing) is in use. Paul
Attempt to make buttons themed
Hi,
to see how easy (or not) it would be to make the controls use themes, I
tried to get themed buttons; the result is the attached patch (to try it
out, you need an .msstyles file and appropriate registry setup). It's
probably not perfect as it is, comments/questions are welcome.
Screenshot:
http://img87.exs.cx/my.php?loc=img87&image=winewiththemedbuttons3xh.png
Some funny side effect when theming is enabled: applications show up in
standard colors, but as soon as the first button is created, the colors
switch to the theme's colors. I guess opening the theme data in the
button code triggers some uxtheme initialization that in turn changes
the system colors.
Also, all applications get themed buttons, which diverges from WinXPs
behaviour and may or may not be desired for some apps.
-f.r.
Index: dlls/user/Makefile.in
===
RCS file: /home/wine/wine/dlls/user/Makefile.in,v
retrieving revision 1.88
diff -u -r1.88 Makefile.in
--- dlls/user/Makefile.in 10 Mar 2005 15:47:53 - 1.88
+++ dlls/user/Makefile.in 21 Mar 2005 18:46:31 -
@@ -4,7 +4,7 @@
SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= user32.dll
-IMPORTS = gdi32 advapi32 kernel32 ntdll
+IMPORTS = gdi32 advapi32 kernel32 uxtheme ntdll
EXTRALIBS = $(LIBUNICODE)
SPEC_SRCS16 = \
Index: dlls/user/button.c
===
RCS file: /home/wine/wine/dlls/user/button.c,v
retrieving revision 1.6
diff -u -r1.6 button.c
--- dlls/user/button.c 23 Dec 2004 17:21:05 - 1.6
+++ dlls/user/button.c 21 Mar 2005 18:46:32 -
@@ -71,6 +71,9 @@
#include "windef.h"
#include "winbase.h"
#include "wingdi.h"
+#include "winuser.h" /* Indirectly required by uxtheme.h */
+#include "uxtheme.h"
+#include "tmschema.h"
#include "wine/winuser16.h"
#include "controls.h"
#include "user_private.h"
@@ -79,7 +82,8 @@
#define STATE_GWL_OFFSET 0
#define HFONT_GWL_OFFSET (sizeof(LONG))
#define HIMAGE_GWL_OFFSET (HFONT_GWL_OFFSET+sizeof(HFONT))
-#define NB_EXTRA_BYTES(HIMAGE_GWL_OFFSET+sizeof(HANDLE))
+#define HTHEME_GWL_OFFSET (HIMAGE_GWL_OFFSET+sizeof(HANDLE))
+#define NB_EXTRA_BYTES(HTHEME_GWL_OFFSET+sizeof(HTHEME))
/* Button state values */
#define BUTTON_UNCHECKED 0x00
@@ -95,6 +99,7 @@
static UINT BUTTON_CalcLabelRect( HWND hwnd, HDC hdc, RECT *rc );
static void PB_Paint( HWND hwnd, HDC hDC, UINT action );
+static void PB_PaintThemed( HWND hwnd, HDC hDC, UINT action );
static void CB_Paint( HWND hwnd, HDC hDC, UINT action );
static void GB_Paint( HWND hwnd, HDC hDC, UINT action );
static void UB_Paint( HWND hwnd, HDC hDC, UINT action );
@@ -123,7 +128,7 @@
typedef void (*pfPaint)( HWND hwnd, HDC hdc, UINT action );
-static const pfPaint btnPaintFunc[MAX_BTN_TYPE] =
+static const pfPaint btnUnthemedPaintFunc[MAX_BTN_TYPE] =
{
PB_Paint,/* BS_PUSHBUTTON */
PB_Paint,/* BS_DEFPUSHBUTTON */
@@ -139,6 +144,22 @@
OB_Paint /* BS_OWNERDRAW */
};
+static const pfPaint btnThemedPaintFunc[MAX_BTN_TYPE] =
+{
+PB_PaintThemed,/* BS_PUSHBUTTON */
+PB_PaintThemed,/* BS_DEFPUSHBUTTON */
+CB_Paint, /* BS_CHECKBOX */
+CB_Paint, /* BS_AUTOCHECKBOX */
+CB_Paint, /* BS_RADIOBUTTON */
+CB_Paint, /* BS_3STATE */
+CB_Paint, /* BS_AUTO3STATE */
+GB_Paint, /* BS_GROUPBOX */
+UB_Paint, /* BS_USERBUTTON */
+CB_Paint, /* BS_AUTORADIOBUTTON */
+NULL, /* Not defined */
+OB_Paint /* BS_OWNERDRAW */
+};
+
static HBITMAP hbitmapCheckBoxes = 0;
static WORD checkBoxWidth = 0, checkBoxHeight = 0;
@@ -183,9 +204,26 @@
return (window_style & 0x0f);
}
+inline static HTHEME get_button_theme( HWND hwnd )
+{
+return (HTHEME)GetWindowLongPtrW( hwnd, HTHEME_GWL_OFFSET );
+}
+
+inline static void set_button_theme( HWND hwnd, HTHEME theme )
+{
+SetWindowLongPtrW( hwnd, HTHEME_GWL_OFFSET, (ULONG_PTR)theme );
+}
+
+inline static const pfPaint* get_paint_funcs ( HWND hwnd )
+{
+HTHEME theme = get_button_theme( hwnd );
+return ( theme != NULL ) ? btnThemedPaintFunc : btnUnthemedPaintFunc;
+}
+
/* paint a button of any type */
inline static void paint_button( HWND hwnd, LONG style, UINT action )
{
+const pfPaint* btnPaintFunc = get_paint_funcs( hwnd );
if (btnPaintFunc[style] && IsWindowVisible(hwnd))
{
HDC hdc = GetDC( hwnd );
@@ -215,6 +253,9 @@
UINT btn_type = get_button_type( style );
LONG state;
HANDLE oldHbitmap;
+static const WCHAR themeClass[] = { 'B','u','t','t','o','n',0 };
+HTHEME theme;
+const pfPaint* btnPaintFunc = get_paint_funcs( hWnd );
pt.x = LOWORD(lParam);
pt.y = HIWORD(lParam);
@@ -249,8 +290,24 @@
if (btn_type >= MAX_BTN_TYPE)
return -1; /* abort */
set_button_state( hWnd, BUTTON_UNCHECKED )
msi.spec different parameter count of exported functions
Hello, when played with native msi.dll i found three functions with have a different parameter count between msi.spec of wine and the native dll. Here are the snoop logs of the native dll and wine: 0009:RET msi.MsiDatabaseImportA(,,) retval=0006 ret=004013fc 0009:RET msi.MsiDatabaseImportW(,,) retval=0006 ret=004013fc 0009:RET msi.MsiCreateAndVerifyInstallerDirectory() retval= ret=004013fc I have used the msi.dll version 2.6.2600.11833 for testing. The question now is: Can we trust the +snoop logging? Bye Stefan
Re: Attempt to make buttons themed
On Mon, 21 Mar 2005 20:05:57 +0100, Frank Richter wrote: > Hi, > to see how easy (or not) it would be to make the controls use themes, I > tried to get themed buttons; the result is the attached patch (to try it > out, you need an .msstyles file and appropriate registry setup). It's > probably not perfect as it is, comments/questions are welcome. Hey, brilliant work! Definitely submit this - it doesn't matter if not everything is themed all at once, this can be a long term project and the approach you've taken seems to be a good one. Yes XP does not theme all apps for compatibility reasons. Once more of our controls are themable I guess we can start to worry about switching it on at the right time. I'd suggest posting this to wine-patches and seeing what happens. Once we get it into CVS, would you be willing to move on and do the other controls? thanks -mike
Re: dlls/user/button.c - fix AUTO3STATE with BS_OWNERDRAW (Resend)
Hi Alexandre,
I was trying to make the following dialog compile and work in WINE. The
dialog compiles and works in Borland.
MSGBOX_DLG DIALOG 21, 32, 168, 83
STYLE DS_MODALFRAME | 0x4L | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Error"
FONT 8, "MS Sans Serif"
{
GROUPBOX "", 101, 6, -2, 157, 61, BS_GROUPBOX | WS_CHILD | WS_VISIBLE
AUTO3STATE "Text", 103, 10, 9, 149, 47, BS_OWNERDRAW | WS_CHILD |
WS_VISIBLE | WS_TABSTOP
PUSHBUTTON "Cancel", 111, 6, 65, 50, 14, BS_PUSHBUTTON | WS_CHILD |
WS_VISIBLE | WS_GROUP | WS_TABSTOP
PUSHBUTTON "Cancel", 112, 58, 65, 50, 14
PUSHBUTTON "Cancel", 113, 110, 65, 50, 14
}
Alexandre Julliard wrote:
Michael Lin <[EMAIL PROTECTED]> writes:
inline static UINT get_button_type( LONG window_style )
{
-return (window_style & 0x0f);
+if ((window_style & BS_OWNERDRAW) == BS_OWNERDRAW)
+return BS_OWNERDRAW;
+else
+return (window_style & 0x0f);
BS_OWNERDRAW is not a bit mask, this won't work right. What is the
problem you are trying to fix?
Re: Eliminate casts of the return value of HeapAlloc
On Mon, Mar 21, 2005 at 02:03:59PM +0100, Francois Gouget wrote: > On Mon, 21 Mar 2005, Alexandre Julliard wrote: > [...] > >Log message: > > Mike McCormack <[EMAIL PROTECTED]> > > Eliminate casts of the return value of HeapAlloc. > > This could be turned into a pretty easy janitorial the starting point of > which would be the output of this command: > > find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" > (344 lines) > > There are a couple of places where the output of HeapAlloc is being cast > to a DWORD but except for those it seems pretty straightforward. Yeah, it's so straightforward, we should just do it. However, I don't think we should sed it, most places require human touch to maintain sane formatting. I'll send in a patch for windows/*.c shortly. -- Dimi.
registry TODO
Alexandre, Recently you removed the loading of the Windows registry on startup and stated that > Nobody's working on it, so it won't be supported until someone cares > enough to do it. I encouraged a few people to start working on it but > nobody did, so taking out the existing support is a way to provide > more encouragement. If that's not enough then the feature simply won't > be supported anymore. What needs to be done concerning this TODO? Looking through Bugzilla I found bug #422: "Currently Wine loads the complete registry into memory at startup. This is relatively ok when the registry is small such as in fake_windows configurations, but when importing the registry fro a Windows partition this can result in the wineserver allocating more than 30MB. This slows down startup times very significantly and wastes memory even if most of it is going to be swapped out. One of the reasons why Wine puts all the registry into memory on startup is that the current registry file format does not lend itself well to random accesses (especially writes). But there is no fundamental reason why Wine needs to read all the registry on startup. Hence this proposal to: * change the registry file format so that Wine can easily make random accesses. A 'database' format may be appropriate here, maybe based on the Berkeley database Library (libdb2/libdb3) or the GNU dbm library (libgbm1, but check license issues). * put in place a mechanism to update these files from the Windows registry files when appropriate (it seems impractical to access the Windows files directly) * modify the registry routines to retrieve only the data required by the application and cache it in memory" Is this a valid description of what needs to be done? -- James Hawkins
Re: NTDLL: teach wine about Mingw32 (RESUBMIT)
Hi, --- "C. Scott Ananian" <[EMAIL PROTECTED]> wrote: > This patch seems to have gotten lost: it was sent last Thursday but hasn't > yet been applied or rejected (as far as I can tell). It's even got a > testimonial from a wine developer: Andreas Mohr says, "Nice patch." =) I don't understand why Mingw does not report the same value as the Windows compiler here. Do you know lcc or and other free compiler based application need this? If not maybe it should be fixed in mingw. Thanks Steven __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
Re: Eliminate casts of the return value of HeapAlloc
Dimitrie O. Paun wrote: Yeah, it's so straightforward, we should just do it. However, I don't think we should sed it, most places require human touch to maintain sane formatting. Well, it's always nice to leave some entry level tasks behind for people who want to start working on Wine. They're really easy to do, but by writing the patch, and submitting it, newcomers can learn alot about the patch submission process. Mike
