Re: commctrl: dialog theming
Evil wrote:
Dreamweaver's "Add Site" (and other) dialog are completely broken when
using the built-in comctl32.
OK, there is a patch that is in CrossOver that has not yet been
committed to WineHQ for some reason, that fixes this problem.
This was known way before I ever started using WINE (because I learned
of it by searching old mailing lists). I even added it to the app
database months back.
Could you please try the attached patch?
I fear that Wine doesn't go forward as much as it should for lack of
testing :/
Mike
Index: dlls/comctl32/tab.c
===
RCS file: /home/mike/src/wine-cvs/wine/dlls/comctl32/tab.c,v
retrieving revision 1.114
diff -u -p -r1.114 tab.c
--- dlls/comctl32/tab.c 11 Aug 2005 18:35:00 - 1.114
+++ dlls/comctl32/tab.c 19 Aug 2005 02:18:21 -
@@ -329,7 +329,18 @@ static BOOL TAB_InternalGetItemRect(
if ( (infoPtr->uNumItem <= 0) ||
(itemIndex >= infoPtr->uNumItem) ||
(!((lStyle & TCS_MULTILINE) || (lStyle & TCS_VERTICAL)) && (itemIndex < infoPtr->leftmostVisible)) )
-return FALSE;
+{
+TRACE("Not Visible\n");
+/* need to initialize these to empty rects */
+if (itemRect)
+{
+memset(itemRect,0,sizeof(RECT));
+itemRect->bottom = infoPtr->tabHeight;
+}
+if (selectedRect)
+memset(selectedRect,0,sizeof(RECT));
+return FALSE;
+}
/*
* Avoid special cases in this procedure by assigning the "out"
Re: commctrl: dialog theming
Vitaliy Margolen wrote: ...So having an option to use native comctl32 is not such a bad idea. I couldn't agree more. I can't imagine that DreamWeaver's the only program that's broken (or will be broken, as new features are added and problems are worked out) when using the built-in implementation. I guess I'll backlevel for now, but I was loving playing with the newest DX patches. -J
Re: [Bug 3165] Patch available
Duane Clark wrote: Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors? I don't really understand how the patch fixed things, but... Riven uses a bunch of color cursors (hands pointing various directions). Without the patch, only the standard pointer cursor was generated. This cursor appeared and disappeared normally (the cursor is supposed to disappear while some Quicktime clips are playing, and then reappear). With the patch, the color cursors reappeared and all are correct. It should improve things over the original code that was there in cursoricon.c revision 1.9. That code first checked if there was only one cursor, then returned it, but if there was more than on cursor, it would choose one a 1bpp cursor. That scheme would miss out picking a cursor at all if there was two coloured cursors. The new scheme makes sure that we always start with one cursor and improve over that. I think the problem is that standard X cannot support coloured cursors. The Xcursor extension appears to, but we don't support that. Any volunteers? Mike
Re: [Bug 3165] Patch available
Kevin DeKorte wrote: On Thursday 18 August 2005 03:24 am, Dripple wrote: Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple. Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors? I don't really understand how the patch fixed things, but... Riven uses a bunch of color cursors (hands pointing various directions). Without the patch, only the standard pointer cursor was generated. This cursor appeared and disappeared normally (the cursor is supposed to disappear while some Quicktime clips are playing, and then reappear). With the patch, the color cursors reappeared and all are correct.
Re: Should all builtin DLLs have version information?
Paul Vriens wrote: > the subject says it all. If yes, I will start adding some for the ones IMHO that's a good idea. -- By By ... ... Detlef
Re: winspool.drv: Conformance-Tests
Felix Nawothnig wrote:
> > While rewriting the conformance-tests for winspool.drv, how should we
> > handle this bugs / features ?
> a) ...
> b) ...
> c) ...
> Disclaimer: These are my personal guidelines, so treat them as such. :-)
Thanks for your hints. I will change some Tests to trace, when i check
for the undocumented results.
In my case, SetLastError() is used, when the Function fails (documented)
and also, when the Function returned SUCCESS (undocumented).
> Just check this on NT then, but avoid using GetVersion() - I'd suggest
> to do something like:
That was my Test:
/* Test for BUG in win9x and wine: Level is not checked */
if((result != FALSE) &&
(strlen(buffer) == (exact-1)))
{
todo("windows")
{
todo_wine
{
ok(0, "BUG in win9x and wine: Invalid Level '0' is" \
" not checked (valid Level is '1')\n");
}
}
}else
{
is_result_ok(FALSE);
is_lasterror_ok(ERROR_INVALID_LEVEL);
is_size_untouched((exact+1));
is_buffer_untouched(buffer, exactbytes);
}
> > I marked that as todo("windows").
> > Is this ok?
>
> No. Until there are other third-party win32 implementations using the
> WRT (Reactos?) we use just todo_wine, nothing else.
OK. I change that.
> > Another Example for GetPrinterDriverDirectory and Enum*:
> > On w2k, the the returned "number of bytes required" in the ANSI-Version
> > is the same as in the Unicode-Version.
> > For GetPrinterDriverDirectory, the rest from the unicode-version of the
> > result is visible in the second part of the buffer.
> > (I Think, w2k fill the buffer with the unicode-version and convert
> > in-place to ANSI. Should we do the same ?)
>
> I'm not sure what you mean here...
Documented is: Return the required number of Bytes for the Buffer.
On W2K the default Driver-Directory is
"C:\WINNT\system32\spool\DRIVERS\W32X86" (38 Characters + Zero).
Optimal Buffersize is 78 Byte for "W" and 39 Byte for "A", but W2k
required a Buffer of 78 Byte for GetPrinterDriverDirectoryA.
A Trace for the Buffer-Contents is:
.c:656:00236438: buffer "C:\WINNT\system32\spool\DRIVERS\W32X86"
.c:661:00236460: buffer+40 L"ool\DRIVERS\W32X86"
> If the function works as documented but fills the rest of the passed
> buffer with undefined stuff (it NUL terminates the first part, right?)
Yes, thats the behavior.
On win9X, the "W"-Version is not implemented and the "A"-Version wants a
Buffer with the optimal Size (18 Byte for "C:\WINDOWS\SYSTEM"+0).
(Wine has a BUG and returned a 19 here. I know how to fix this, but I
want to get the tests in the CVS first).
> we shouldn't test for it unless we find an app which depends on it.
I will change the relevant Tests to trace.
--
By By ...
... Detlef
Re: RICHED20: Avoid flicker
On Sun, 14 Aug 2005 17:53:33 +0400 Phil Krylov <[EMAIL PROTECTED]> wrote: > this patch needs to be applied after the "Re: RICHED20: Implement > EM_SETRECT, EM_SETRECTNP and WM_SETREDRAW messages (fixed)" patch. > > ChangeLog: > > Avoid flicker in RichEdit using proper update region invalidation and an > offscreen bitmap. Anything wrong with this patch? -- Ph.
Re: [Bug 3165] Patch available
On Thursday 18 August 2005 03:24 am, Dripple wrote: > Hi, > > I tested the patch submitted in > http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. > Seems to fix the issue. > > Regards. > > Dripple. Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors? Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351 pgpPT4iKZZbw8.pgp Description: PGP signature
Re: Cursor disappears and reappears
I suspect this may not be in Wine at all. There is currently a problem that shows up both in and out of Wine with the cursor vanishing permanently until reboot on some games that block or change the cursor. This appears to be a problem in FC but I have not had time to track it down.
Re[2]: commctrl: dialog theming
Thursday, August 18, 2005, 12:10:39 AM, Mike McCormack wrote: > Evil wrote: >> I'm no longer able to run programs that require the native comctl32 and >> commctrl DLLs, since updating to today's CVS. Could it be related to >> these theme patches? > You shouldn't need to use the native comctl32 any longer. Please update > your dll overrides to "comctl32" = "builtin". > Wine's comctl32 implementation is almost complete. If there's bugs with > the builtin comctl32 then please help us by reporting them rather than > sweeping the problem under the carpet and using the native dll. To fuel this fire a little bit, I should mention that ATM all themed controls are broken with all Delphi and possible some other programs. So having an option to use native comctl32 is not such a bad idea. Vitaliy.
[Bug 3165] Patch available
Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple.
Re: commctrl: dialog theming
Andreas Mohr wrote: Just to verify: are you sure that you're *either* running both commctrl.dll and comctl32.dll as native *or* both commctrl.dll and comctl32.dll as builtin? Otherwise it *will* fail, with a thunk error similar (or equal?) to above. Yes, using both native is when I get the aforementioned failure. Dreamweaver starts if you use both built-in, but there are broken dialogs that can't be used. -J
Re: commctrl: dialog theming
Mike McCormack wrote: You shouldn't need to use the native comctl32 any longer. Please update your dll overrides to "comctl32" = "builtin". Wine's comctl32 implementation is almost complete. If there's bugs with the builtin comctl32 then please help us by reporting them rather than sweeping the problem under the carpet and using the native dll. Dreamweaver's "Add Site" (and other) dialog are completely broken when using the built-in comctl32. This was known way before I ever started using WINE (because I learned of it by searching old mailing lists). I even added it to the app database months back. -Jesse
Re: winspool.drv: Conformance-Tests
Detlef Riekenberg wrote:
I wrote a Commandline-Program for testing the Printing-API and found
many misterious behaviour.
While rewriting the conformance-tests for winspool.drv, how should we
handle this bugs / features ?
There are several types of undocumented behaviour:
a) The documentation is plain wrong and applications will most likely
depend on the documented behaviour (often hard to tell - an example
would be a function which is supposed to return the needed buffer size
but misbehaves under some conditions):
In this case test for the documented behaviour, comment it out using
#if 0 and add a note that foobar32.dll Version 1.2.3.4 does not work
as documented.
b) The documentation is plain wrong and it's likely that applications
using the API will rely on the undocumented behaviour (for example if
MSDN got the argument order wrong):
In this case test for the undocumented behaviour and add a comment
telling that this is undocumented.
c) The documentation is wrong, misleading or incomplete and although
applications should not rely on the undocumented behaviour you found one
which does (for example if a function reports failure instead of
segfaulting when it retrieves a bad pointer):
In this case test for the undocumented behaviour and add a comment
telling which application depends on this undocumented behaviour.
Any other undocumented behaviour should not be tested for at all.
Disclaimer: These are my personal guidelines, so treat them as such. :-)
Example for GetPrinterDriverDirectory (W/A):
Win98se and WinME do not check the requested level
Just check this on NT then, but avoid using GetVersion() - I'd suggest
to do something like:
ret = GetPrinterDriverDirectoryW(foo);
if(ret != ERROR_CALL_NOT_IMPLEMENTED)
{
/* Here you can test stuff which fails on 9x/ME */
}
else trace("GetPrinterDriverDirectoryW not implemented, skipping tests\n");
/* ... and here the stuff which successeds on both 9x/ME and NT */
I marked that as todo("windows").
Is this ok?
No. Until there are other third-party win32 implementations using the
WRT (Reactos?) we use just todo_wine, nothing else.
Another Example for GetPrinterDriverDirectory and Enum*:
On w2k, the the returned "number of bytes required" in the ANSI-Version
is the same as in the Unicode-Version.
I'd handle this like a).
We probably want our implementation to work as documented (since this is
most likely what apps will depend on) but we can't test it since it
would fail on Windows - so we comment out the test.
For GetPrinterDriverDirectory, the rest from the unicode-version of the
result is visible in the second part of the buffer.
(I Think, w2k fill the buffer with the unicode-version and convert
in-place to ANSI. Should we do the same ?)
I'm not sure what you mean here...
If the function works as documented but fills the rest of the passed
buffer with undefined stuff (it NUL terminates the first part, right?)
we shouldn't test for it unless we find an app which depends on it.
Felix
