- FIXME("(%x),stub!\n",hrasconn);
+ FIXME("(0x%08lx): stub\n", (DWORD) hrasconn);
[...]
I think I would rather use %p to print handles. After all they are
pointers, not integers. The annoying aspect of it is that %08p is not
very well supported IIRC. Maybe gcc has been fixed though.
I forgot to mention it before. But I assume you saw bug #90.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
Advice is what we ask for when we already know the answer but wish we didn't
-- Eric Jong
Hi everybody:
Has anybody tried to run wine on a High Availabity cluster ?. Especifically
we are interested on a Mosix environment where applications don't need be
changed.
The windows application to be clustered is a Remote IP network back-up system
so no grafic intensive or plug modern like ActiveX and so.
Any comments are highly apreciated
thanks
lsla(a)post.cz writes:
> Where the Wine's GetClipRect returns the area of the parent, the
> Windows version returns only the area of the child. Therefore in
> Wine the WM_ERASEBKGND message erases the whole parent including the
> other radio buttons.
I think GetClipBox is correct, the problem is that the WM_ERASEBKGND
handler should not be using it, but GetClientRect. You can try this:
Index: windows/defwnd.c
===================================================================
RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v
retrieving revision 1.57
diff -u -r1.57 defwnd.c
--- windows/defwnd.c 2001/06/20 23:16:34 1.57
+++ windows/defwnd.c 2001/07/27 23:47:26
@@ -457,20 +457,15 @@
case WM_ICONERASEBKGND:
{
RECT rect;
+ HDC hdc = (HDC)wParam;
HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND );
if (!hbr) return 0;
- /* Since WM_ERASEBKGND may receive either a window dc or a */
- /* client dc, the area to be erased has to be retrieved from */
- /* the device context. */
- GetClipBox( (HDC)wParam, &rect );
-
- /* Always call the Win32 variant of FillRect even on Win16,
- * since despite the fact that Win16, as well as Win32,
- * supports special background brushes for a window class,
- * the Win16 variant of FillRect does not.
- */
- FillRect( (HDC) wParam, &rect, hbr );
+ /* GetClientRect used to be GetClipBox, but it is not what
+ * Windows does, and it breaks badly with CS_PARENTDC */
+ GetClientRect( wndPtr->hwndSelf, &rect );
+ DPtoLP( hdc, (LPPOINT)&rect, 2 );
+ FillRect( hdc, &rect, hbr );
return 1;
}
--
Alexandre Julliard
julliard(a)winehq.com
> make_filter: : can't parse output: 'Make.rules.in is newer
> than Make.rules, please rerun ./configure!'
Fixed in my tree.
> Would it be possible to have the messages pass through as-is when
> they are not recognized (with the current directory for context)?
[snip]
> make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817:
> warning: unused variable `xvis''
I have fixed that for gcc messages (unless --pedantic is specified),
however I'm not sure it is good always doing that. I will think
about it.
> It looks like there's an incompatibility with colorgcc.
[snip]
> So it must be the controls characters added by colorgcc
> that confuse
> make_filter.
No it wasn't, colorgcc checks whether STDOUT is a TTY or not.
> > But OK I will try and compile with -DSTRICT and see what happends.
> > IIRC somebody tried that but it didn't turn out so well.
>
> That would be me, probably. I started the conversion to -DSTRICT but
> then other priorities came up and now it's on the back burner. I will
> get back to it eventually but at the current rate it's hard
> to know when
> that will be :-(
> Compiling with -DSTRICT is not that bad: with a relatively simple
> patch it compiles (see attachement). Or at least, it used to.
No patch is needed for the file in question.
windows/property.c needs a simple patch though.
> But there
> are tons of warnings, which means tons of places that need
> attention and
> possibly fixing. That's where the work is.
Yes. I've noticed that and I have fixed a few of them as well.
However I'm not optimistic on fixing them all on the short term.
The problem is not the number of them, the problem is that
some of the warnings like the Global* can't be fixing in
the .c files. It involves changing the .h files and that
generated even more warnings. :-(
I will investigate furher, but as I said, I'm not optimistic.
>From: Francois Gouget <fgouget(a)free.fr>
>To: José Soriano Díaz <jose__sor(a)hotmail.com>
>CC: wine-devel(a)winehq.com
>Subject: Re: native dll's
>Date: Thu, 26 Jul 2001 10:10:17 -0700 (PDT)
>
>On Wed, 25 Jul 2001, José Soriano Díaz wrote:
>
> >
> > Hi there, I'm working in a telerobotics project and I need to
>link a
> > windows dll in order to use a Cybernet Joystick.
> > First I tried to use the winAPI functions LoadLibrary,
> > FreeLibrary and GetProccessAddress as I were working on Windows, and
> > I recompiled my program with winelib:
> > *. winemaker /my_path/
> > *. ./configure
> > *. make all
> > but it didn't create any executable, what I obtained was a
> > lib*.so, because winemaker thought I was trying to compile a dll,
> > not to use one.
>
> To force winemaker to generate an executable simply use it as
>follows:
> * type "winemaker --cuiexe /my_path" to indicate a console executable
> * type "winemaker --guiexe /my_path" to indicate a graphical executable
>
> You can also use "winemaker -?" to get a list of options supported by
>winemaker.
>
>
> > So my question is quite siple How can I link a native dll in
> > a Unix project?
>
> I think you have used the right approach: LoadLibrary /
>GetProccessAddress / FreeLibrary. If that works for you then it's the
>simplest approach.
I'm afraid it doesn't work, when I executed what I compiled , I obtained
"Undefined Symbol" in any call to the native dll. Thanks anyway for the
advice.
_________________________________________________________________
Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp
Travis Michielsen wrote:
>
> What about GetCharABCWidth* what does this function use? (or could it use
> this?) I see the function still shows a fixme (or atleast the last time I
> checked).
>
The only one that works for printer fonts is GetCharABCWidthsFloat. I
just tested it on Windows 2000 and verified that it always returns 0 for
abcfA and abcfC (and returns the advance width in abcfB) when it is
called on a printer font.
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
> > This patch partially implements the ChangeDisplaySettings* functions.
>
> Well, I am 100 % sure that Alexandre will reject it :-)
:-\
> If you want to do something like that, you need to implement the feature in
> the X11 driver and then call it via the 'USER_Driver.pFunctionName'
> protocol.
Hmm, I was going to try something like that, however, I had problems with that
method simply b/c of the load order between the dlls. ChangeDisplaySettings is
implemented in user32.dll which loads BEFORE x11drv. This makes it impossible
to initalize the function with the user32.dll. However, with DDraw, the
x11drv.dll is loaded before the ddraw.dll! The only way I saw to exchange info
was to initialize the function with a call from x11drv.dll. If you can suggest
an alternative that takes load order into account I will likely use it.
> Moreover, there are already some DDraw-related mode change functions (in
> dlls/x11drv/xvidmode.c). This should be factorized between both code.
Already using so of that code, although it could probably be cleaned up a bit.
I will get to that soon.
- Travis Michielsen
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--- Bill Medland <medbi01(a)accpac.com> wrote:
> I don't like submitting incomplete code but I may have little choice unless
> someone can point me in the correct direction here. As you may guess from
> the following, my Windows experience is not that extensive but I think it's
> enough to allow me to make sensible contributions.
>
> I am working on correcting the LISTVIEW_DrawLargeItem function, especially
> when the item text is large. I have already got most of the way. However
> the problem is this.
>
> When a user selects a large icon the text should be written completely (by
> calling DrawText with DT_NOCLIP). It is doing so; I can prove it by
> resizing the window and I will see the full text being displayed for a
> selected item. However when drawing it at the moment of selecting it, the
> text is being clipped to the usual two and a bit rows. Presumably this
> means that there is a clipping rectangle in the DC or the window that I
> need to inflate. Or Do I simply invalidate that rectangle (from within the
> WM_PAINT handler!!!).
>
> Any help would be appreciated.
>
> Bill
Looking at the DrawText code I see that DrawText just passes the NOCLIP flag to
ExtTextOut, so the problem I likely not with DrawText but with ExtTextOut
instead. I can take a look at the code for both functions (time providing) and
find out what is happening.
- Travis Michielsen
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Currently, the Wine PostScript driver stores the bounding box (xMin,
yMin, xMax, yMax) for every glyph in every font. This information is
not currently used, and I'd like to get rid of it. (Note: this is
distinct from the advance width of each glyph, which is certainly
required.)
>From what I can tell, there is no API that a Win32 application or the
Windows GDI can use to get this information from a printer driver.
Since I'm not that familiar with either, however, I figure I should try
to confirm that this is indeed the case.
So, does anyone know of any API that an application or the GDI can use
to get the dimensions of an individual glyph from a "real" Windows
printer driver? (I have verified that calling the GetTextExtentPoint
functions with a one-character string returns the height of the font,
not the height of the glyph. For example, it returns the same height
for 'A' and '_'.)
Thanks!
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================