https://bugs.winehq.org/show_bug.cgi?id=44748
Bug ID: 44748
Summary: Crystal Reports XI: Number fields are invisible
Product: Wine
Version: 3.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: twilightinzero(a)gmail.com
Distribution: ---
Created attachment 60759
--> https://bugs.winehq.org/attachment.cgi?id=60759
Console output with WINEDEBUG=""
I have installed Crystal Reports XI in its own wine prefix. The tricks I have
currently run on it to fix 44208 and another unreported issue are riched20 and
ie8. I also ran corefonts on it to try and fix this to no avail.
Number fields and their placeholders are currently invisible, both in design
view and preview. They are also invisible in the dialogs that are used to
configure them. *However*, that is only if they are standalone fields. If I
drag a number field into a text box, I can see the placeholder and the
resulting number. But I still can't see it in the formatting dialog.
--
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=45097
Bug ID: 45097
Summary: Wrong process name when using CreateProcess from
kernel32
Product: Wine
Version: 3.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: sr-tream(a)yandex.ru
Distribution: ---
After using CreateProcess from kernel32 on Linux, lpCommandLine is used as the
process name, although lpApplicationName should be used.
=================================================================================
BOOL WINAPI CreateProcess(
_In_opt_ LPCTSTR lpApplicationName,
_Inout_opt_ LPTSTR lpCommandLine,
_In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes,
_In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes,
_In_ BOOL bInheritHandles,
_In_ DWORD dwCreationFlags,
_In_opt_ LPVOID lpEnvironment,
_In_opt_ LPCTSTR lpCurrentDirectory,
_In_ LPSTARTUPINFO lpStartupInfo,
_Out_ LPPROCESS_INFORMATION lpProcessInformation
);
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45099
Bug ID: 45099
Summary: SetWindowPlacement doesn't restore the normal position
correctly
Product: Wine
Version: 3.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: vz-wine(a)zeitlins.org
Distribution: ---
Consider an application which calls GetWindowPlacement() on its main window to
store its geometry on exit and SetWindowPlacement() on startup to restore the
previously stored values. If the window of such application is maximized on
exit, then the window is correctly restored to the maximized state during the
next run, but restoring this window, i.e. returning it to the normal,
unmaximized state, doesn't restore it to the previous position (although it
does restore its size).
Here are some excerpts from the logs I see with WINEDEBUG=win for the last
execution:
0009:trace:win:WINPOS_SetPlacement 0x10050: setting min 0,0 max 0,55 normal
(3440,1910)-(3840,2160) flags 6 ajusted to min 0,0 max 0,55 normal
(3440,1910)-(3840,2160)
0009:trace:win:SetWindowPos hwnd 0x10050, after (nil), 3440,1910 (400x250),
flags 00000014
...
0009:trace:win:WINPOS_MinMaximize 0x10050 3
0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal
(3440,1910)-(3840,2160)
0009:trace:win:GetWindowRect hwnd 0x10050 (3440,1910)-(3840,2160)
... I restore the window here ...
0009:trace:win:WINPOS_MinMaximize 0x10050 9
0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal
(3440,1910)-(3840,2160)
... almost immediately after ...
0009:trace:win:USER_SetWindowPos status flags = 1807
0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155)
0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155)
0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155)
0009:trace:win:GetWindowRect hwnd 0x10050 (3440,1910)-(3840,2160)
0009:trace:win:SetWindowPos hwnd 0x10050, after (nil), 115,87 (400x250), flags
00000015
... when closing the program ...
0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal
(115,87)-(515,337)
I.e. SetWindowPlacement() is passed the correct position (3440,1910
corresponding to the lower right corner), and even restoring it still uses the
same correct position, but then the window is somehow moved to the wrong
position (115,87) for some reason which I don't understand.
This is just a minor irritant, of course, but I'd still like to open this bug
just in case it's also simple to fix.
--
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=45100
Bug ID: 45100
Summary: System.AccessViolationException for .Net when Form
start
Product: Wine
Version: 3.7
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alekseenko_yan(a)mail.ru
Created attachment 61271
--> https://bugs.winehq.org/attachment.cgi?id=61271
Crashed log from Wine
I try to start Zeus Radio (hfrelectronics.com) written on .Net and using
DirectSound and OpenGL and application crashed.
PS. We try to start on Wine 3.6 under Linux Mint ant it WORKS.
Unhandled Exception: System.AccessViolationException: Attempted to read or
write protected memory. This is often an indication that other memory is
corrupt.
at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd, Int32
nCmdShow)
at System.Windows.Forms.Form.set_WindowState(FormWindowState value)
at CustomControls.CustomForm.OnLoad(EventArgs e) in
d:\Project\ZeusSDR\ZeusSDR\ui\Controls\CustomForm.cs:line 154
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at CustomControls.CustomForm.WndProc(Message& m) in
d:\Project\ZeusSDR\ZeusSDR\ui\Controls\CustomForm.cs:line 572
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)
at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd, Int32
nCmdShow)
at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
at System.Windows.Forms.Control.Show()
at ZeusSDR.ZeusMainForm..ctor(Intro intro) in
d:\Project\ZeusSDR\ZeusSDR\ui\ZeusMainForm.cs:line 568
--
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.