https://bugs.winehq.org/show_bug.cgi?id=44633
Bug ID: 44633
Summary: Checboxes and Radiobuttons blank out the text area
that follows them
Product: Wine
Version: 3.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: ryampolsky(a)yahoo.com
Distribution: ---
Because it's not possible to control the text color for themed checkboxes and
radiobuttons, I have implemented a kludge in my app that works on Windows, but
not WINE. I create checkboxes and radiobuttons as two widgets: the button,
with a null text string (but sized as if it contained the text so that clicking
on the text still activates the button), followed by a static text item for the
label, which I draw in black or white depending on the background color.
I process the WM_CTLCOLOR... messages, and set the background mode to
TRANSPARENT, but I return a non-null background brush. If I don't do that, the
button's focus rectangle doesn't go away when it loses focus. But since the
text is null, Windows doesn't draw anything where the text would go. My static
text control draws in the same place - resulting in what looks like a normal
check/radiobutton, but with the text in the color I want.
This works fine on Windows, and I think it used to work under WINE (but don't
quote me - this is a recent feature, and I may have never tested it under a
prior version of WINE). In version 3.2 at least, the radiobutton or checkbox
seems to be overwriting my static text control - so that I don't see the text
at all. I.e., WINE is drawing the full text rectangle, even though it contains
a null string. Either Windows only draws the rectangle for the actual 0-sized
text string, or it's order of operations allows my static text to remain
visible. But in Windows, there's no 'flashing' of the text, so I suspect the
background rectangle is being sized to the null string and the static label is
never erased and redrawn.
In WINE, when I click the radiobutton, I can see my static text label flash on
- but it is immediately overwritten by a blank text rectangle drawn by WINE.
Yes, my code is a bit of a kludge, but it works on Windows (and I know of no
other way to control the color of check/radiobutton text). It'd be nice if it
worked on WINE too, no?
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41438
Bug ID: 41438
Summary: fastone image viewer 5.9 "crop" window do not show if
called by hotkey from full screen mode
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: unxed(a)mail.ru
Distribution: ---
steps to reproduce:
1. get faststone image viewer from here:
http://www.faststone.org/FSViewerDownload.htm
2. select any image
3. press "enter" to go to fullscreen mode
4. prexx "x" for crop properties window
5. the window will be shown in background, with no way to switch to it:
actually unusable
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=30762
Bug #: 30762
Summary: msxml3/domdoc tests flaky
Product: Wine
Version: 1.5.4
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msxml3
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Classification: Unclassified
ca48dac8821e128db8991dc54b4dedc8c321e816 and
9c0486d7a802c2f618a56a2074c5d790d329e3cf
both seem to have introduced some flaky tests in msxml3/domdoc.
Here's the result of 455 runs in a loop on ubuntu 12.04 (though I
also saw these on Centos 6):
342 domdoc.c:11537: Test failed: got L"http://blahblah.org"
342 domdoc.c:11542: Test failed: got L"http://blah.org"
350 domdoc.c:11647: Test failed: got L"http://blahblah.org"
350 domdoc.c:11652: Test failed: got L"http://blah.org"
3 domdoc.c:2098: Test failed: can't create file
C:\users\dank\Temp\leading_spaces.xml: 32
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28578
Bug #: 28578
Summary: Editing a wiki page strips out carriage returns from
all preformatted text on that page
Product: WineHQ.org
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dimesio(a)earthlink.net
Classification: Unclassified
This most recently happened with the Regression Testing page (bug 28575), but
I've seen it before on other pages: carriage returns are removed from
preformatted text, even if that part is not edited directly, and the
preformatted text turns into an unreadable mess. It used to be possible to
avoid this by staying in GUI mode and not previewing, but that seems to no
longer work.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33470
Bug #: 33470
Summary: Don't allow to create wiki pages with external links
Product: WineHQ.org
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dmitry(a)baikal.ru
CC: dimi(a)lattica.com
Classification: Unclassified
Just have a look at http://wiki.winehq.org/RecentChanges, it really starts
to take quite a bit of an effort to clean Wine wiki from spam.
Apparently, spammers can't be stopped by keywords listed in the stop list
http://wiki.winehq.org/LocalBadContent, and that's another problem.
Disallowing to create wiki pages with external links is considered main and
very efficient way to stop wiki spam, there are many resources explaining how
to do that for various wiki engines.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40642
Bug ID: 40642
Summary: Show windows application menu in OS X global menubar
Product: Wine
Version: 1.9.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: winemac.drv
Assignee: wine-bugs(a)winehq.org
Reporter: f.platte(a)platte-web.de
Distribution: ---
The MacDriver has evolved significantly from when it was introduced and I have
no need to use the X11 window environment since quiet some time. However what
is still missing menubar integration. I don't know if this ever was planed,
however I think this is one of the most logical progression for wine on OS X.
I'm posting this now because I just came across a windows tool which does
exactly that. While there were always attempts to theme windows like OS X and
emulating the global menubar now someone found a way to do just that
(http://lee-soft.com/el-capitan-menubar-for-windows/). So as it's possible to
extract windows applications' menus it might be possible to integrate them into
OS X's menubar as GTK and Java can inject menus there, too.
While I related this "bug report" to the MacDriver and OS X it might also be
useful for Ubuntu, as it (optionally) also features a global menubar.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43231
Bug ID: 43231
Summary: Dai-Senryaku Perfect 3.0:Not draw background with GDI.
Product: Wine
Version: 2.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: whatisthis.sowhat(a)gmail.com
Distribution: ---
When playing Dai-Senryaku Perfect 3.0 for PC (大戦略バーフェクト3.0
http://www.ss-alpha.co.jp/products/dsperfect3.html ), using with GDI as DDraw
renderer, not show background and map.
When using OpenGL as renderer, background and map were drawn, but, very slowly.
Too slow to unplayable.
With Wine 2.0, with GDI, play fine.But with 2.0 with OpenGL, very slowly.
Note:
1. Trial version is available:
http://www.ss-alpha.co.jp/download/dsperfect3_tk.html
2. For product version, set registry values to "DSP3.bin", do not set to
"DSP3.exe".
Regards.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43971
Bug ID: 43971
Summary: Wine 2.20 Bcrypt compilation fails under older linux
systems while Wine 2.0.3 compiles fine
Product: Wine
Version: 2.20
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bcrypt
Assignee: wine-bugs(a)winehq.org
Reporter: vfrederix(a)gmail.com
Distribution: ---
LOG:
make[1]: Entering directory
`/home/frd/Software_Packages/source_compile/wine/builds/wine-2.20/dlls/bcrypt'
gcc -c -o bcrypt_main.o bcrypt_main.c -I. -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe \
-fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
-Wignored-qualifiers \
-Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla
-Wwrite-strings -Wpointer-arith \
-Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
bcrypt_main.c:830:1: error: ‘key’ defined as wrong kind of tag
{
^
make[1]: *** [bcrypt_main.o] Error 1
make[1]: Leaving directory
`/home/frd/Software_Packages/source_compile/wine/builds/wine-2.20/dlls/bcrypt'
make: *** [dlls/bcrypt] Error 2
GCC version: 4.8.1
Configure output:
configure: libgnutls development files too old, bcrypt encryption won't be
supported.
So why is bcrypt compilling ?
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.