Hi, all!
I was playing around systray icons in various modes
1)
"allow the window manager to control the windows"="on"
"emulate a virtual desktop"="off"
As result, systray icon is OK.
2) In other combination of these parameters, the icon is drawn with window
title.
I've tried to investigate the problem and created the patch (attached).
But it solves the problem only in non-desktop modes.
In desktop modes only window title is drawn.
So the questions:
1) Does systray icon helper window really need to be created with WS_CAPTION
style?
2) What does "managed" mode mean?
3) When I select "desktop" mode, should we disable the "managed" checkbox?
Thanks in advance,
-- Kirill K. Smirnov
On Monday 25 December 2006 11:22, Paul Vriens wrote:
> These are the MinGW packages I'm currently using:
>
> mingw-binutils-2.16.91-9hl
> mingw-w32api-3.6-18hl
> mingw-gcc-core-3.4.5-13hl
> mingw-runtime-3.9-18hl
I think I'll get around to building a new set of RPMs this week.
Lets go for a Wine 1.0 release without any failing test on XP.
-Hans
Am 28.12.2006 um 03:12 schrieb H. Verbeet:
> Most of the places that use D3DCOLORTOGLFLOAT4 can handle GLint's
> just as well.
>
> Changelog:
> - Where possible, avoid using D3DCOLORTOGLFLOAT4
> <wined3d_d3dcolor.diff.txt>
>
This patch causes a regression in Battlefield 1942, a lot of geometry
is missing(ships, planes, parts of trees).
Dmitry wrote:
> "Vijay Kiran Kamuju" <infyquest at gmail.com> wrote:
>> What do we need to setup, if we want a test framework for messages in
>> comctl32 similar to user32?
>
>Some kind of a message queue is needed and a mechanism to check what
>has been gathered with an expected sequence. I'd suggest to not invent
>a wheel and copy existing parts from dlls/user32/tests/msg.c.
Yeah. Also I think James Hawkins is doing this now for
comctl, might check with him first.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Vitaly just pointed out that the previous version added some extra spaces. This one fixes that.
Roderick
> Hi,
>
> This patch fixes a nasty wglGetProcAddress bug. In case the name of an
> unknown GL extension (one which is not in wine yet) was passed to
> wglGetProcAddress it was assumed that it was a WGL extension.
>
> WGL extensions are in the end looked up in winex11.drv. The
> wglGetProcAddress function in winex11.drv can return WGL extensions but it can also
> return native GL functions. This ability is used in order to fill the opengl32
> thunks (win32 GL -> native GL).
>
> The problem was that unknown extensions were also passed to the
> winex11.drv code. This resulted that code to look up a native GL functions (the
> winex11.drv code returns wgl extensions if the function name starts with 'wgl'
> and else it calls glXGetProcAddress).
>
> In the end this patch makes sure that only functions which start with a
> 'w' are passed to the winex11.drv code in the other cases a warning is
> printed that the function wasn't found.
>
> Regards,
> Roderick Colenbrander
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Hello,
I noticed that you are using function_grep.pl to search for
a certain function.
Have you considered GNU idutils?
They can do that and more (and faster):
http://www.gnu.org/software/idutils
It is as simple as
$ cd $WINE_SRC_PATH
$ mkid (generate ID database, takes about 4 seconds on my machine for wine)
$ gid -r PATTERN
Claudio
I get an error when running a windows console program on wine. It
appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't return a
handle to a console so GetConsoleMode() on that handle fails. The
actual programs that fail are at: http://simh.trailing-edge.com/
Here is a simple patch to kernel32/tests/console.c to demonstrate the
problem:
diff -p -u -r1.2 console.c
--- dlls/kernel32/tests/console.c 10 Oct 2006 18:19:57 -0000 1.2
+++ dlls/kernel32/tests/console.c 20 Dec 2006 07:20:06 -0000
@@ -552,12 +552,31 @@ static void testCtrlHandler(void)
ok(GetLastError() == ERROR_INVALID_PARAMETER, "Bad error %u\n", GetLastError());
}
+static void test(void)
+{
+ HANDLE std_input;
+ DWORD saved_mode;
+
+ std_input = GetStdHandle(STD_INPUT_HANDLE);
+ ok(std_input != INVALID_HANDLE_VALUE,
+ "GetStdHandle(STD_INPUT_HANDLE) returned INVALID_HANDLE_VALUE\n");
+
+ if (std_input != INVALID_HANDLE_VALUE)
+ {
+ BOOL status;
+ status = GetConsoleMode(std_input, &saved_mode);
+ ok(status != FALSE, "GetConsoleMode() failed: %08x\n", GetLastError());
+ }
+}
+
START_TEST(console)
{
HANDLE hConIn, hConOut;
BOOL ret;
CONSOLE_SCREEN_BUFFER_INFO sbi;
+ test();
+
/* be sure we have a clean console (and that's our own)
* FIXME: this will make the test fail (currently) if we don't run
* under X11
Adding a data point to the ALSA and Wine sound discussion.
ALSA has a general problem with:
* Doubling volume
* Playing sound bites two times
when it doesn't receive data fast enough from an application.
I tried playing a video file over a network using a non-wine player,
then paused the network stream. The sound paused.
Then restarted the network stream.
The volume now doubles for the next sound bite (always), and the next
sound bite is played twice (sometimes).
So, just in case anyone is hearing the above two effects, they may
actually be bugs in ALSA occuring when samples are delivered slower
than expected, rather than bugs in Wine.
Hi folks,
over christmas, I decided to give make test another try.
I'm running this on an openSUSE 10.1 box, ati radeon mobility x300 with open
source drivers. (Probably unimportant for the errors I'm getting)
My procedure to get the tests setup were:
export WINEPREFIX=~/.wine-test
rm -rf $WINEPREFIX
wineprefixcreate
winecfg (set to emulate virtual desktop, nothing else touched)
make test
This fails in user32, with the attached error message:
Any thoughts?
Cheers,
Kai
--
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.