http://bugs.winehq.org/show_bug.cgi?id=9027
--- Comment #22 from Sebastian Doering <moralapostel(a)gmail.com> 2009-03-13 19:31:58 ---
(In reply to comment #21)
> (In reply to comment #20)
> > I disagree this bug is fixed. The game's demo doesn't work on my box as
> > expected.
> >
>
> File a new bug.
>
maybe i am being dumb here: But why should a new bug be filed, if the original
bug doesnt seem to be fixed? Kind of useless to open a new bug for exactly the
same problem.
Or is this standard procedure for wine development to create a new bug when an
old bug has wrongly been marked as Fixed?
--
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=9027
--- Comment #21 from Austin English <austinenglish(a)gmail.com> 2009-03-13 12:35:51 ---
(In reply to comment #20)
> I disagree this bug is fixed. The game's demo doesn't work on my box as
> expected.
>
File a new bug.
--
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=9027
--- Comment #20 from Saulius K. <saulius2(a)gmail.com> 2009-03-13 11:18:37 ---
I disagree this bug is fixed. The game's demo doesn't work on my box as
expected.
--
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=17636
Summary: urlmon: protocol test fails with +heap enabled
Product: Wine
Version: 1.1.16
Platform: PC-x86-64
URL: http://test.winehq.org/data/3db77ce50b9dfa811966afe15604
ce2ee3e20c8e/wine_ae-ub-904-heap/urlmon:protocol.html
OS/Version: Linux
Status: NEW
Keywords: download, regression, source
Severity: minor
Priority: P2
Component: wininet
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Created an attachment (id=19823)
--> (http://bugs.winehq.org/attachment.cgi?id=19823)
+relay,+seh,+tid,+wininet
Backtrace:
=>0 0xaaaaaaaa (0x0032dc38)
1 0x60b47744 SendAsyncCallback+0x184(hdr=0x13ef28, dwContext=2863311530,
dwInternetStatus=<register EDI not in topmost frame>, lpvStatusInfo=(nil),
dwStatusInfoLength=0) [/home/austin/wine-git/dlls/wininet/utility.c:366] in
wininet (0x0032dca8)
2 0x60b2343e FTP_ReceiveResponse+0x5e(lpwfs=0x13ef28, dwContext=2863311530)
[/home/austin/wine-git/dlls/wininet/ftp.c:2622] in wininet (0x0032dcf8)
3 0x60b2378b FTPFILE_Destroy+0x5b(hdr=<register EDI not in topmost frame>)
[/home/austin/wine-git/dlls/wininet/ftp.c:1104] in wininet (0x0032dd28)
4 0x60b38ac4 WININET_Release+0xb4(info=<register ESI not in topmost frame>)
[/home/austin/wine-git/dlls/wininet/internet.c:202] in wininet (0x0032dd58)
5 0x60b3a868 WININET_FreeHandle+0x178(hinternet=0x2)
[/home/austin/wine-git/dlls/wininet/internet.c:238] in wininet (0x0032dda8)
6 0x60b3a8ff InternetCloseHandle+0x3f(hInternet=<register ESI not in topmost
frame>) [/home/austin/wine-git/dlls/wininet/internet.c:1149] in wininet
(0x0032ddd8)
7 0x60354ba0 call_entry_point+0x20() in ntdll (0x0032ddf8)
8 0x60356ca8 relay_call+0x168(descr=0x60b52efc, idx=65658, stack=0x32de5c)
[/home/austin/wine-git/dlls/ntdll/relay.c:399] in ntdll (0x0032de48)
9 0x60b1e1d1 in wininet (+0xe1d1) (0x0032de78)
10 0x606cf8c6 FtpProtocol_Terminate+0x66(iface=0x13e430, dwOptions=0)
[/home/austin/wine-git/dlls/urlmon/ftp.c:178] in urlmon (0x0032dea8)
11 0x6068d9ff test_protocol_terminate+0xdf(protocol=<register ESI not in
topmost frame>) [/home/austin/wine-git/dlls/urlmon/tests/protocol.c:1596] in
urlmon_test (0x0032ecf8)
12 0x6068eb3d test_ftp_protocol+0x5bd()
[/home/austin/wine-git/dlls/urlmon/tests/protocol.c:1843] in urlmon_test
(0x0032fd58)
13 0x60691a14 func_protocol+0x1e4()
[/home/austin/wine-git/dlls/urlmon/tests/protocol.c:1854] in urlmon_test
(0x0032fdc8)
14 0x606a0068 run_test+0x138(name="protocol.c")
[/home/austin/wine-git/dlls/urlmon/tests/../../../include/wine/test.h:456] in
urlmon_test (0x0032fe18)
15 0x606a0269 main+0x129(argc=<register ECX not in topmost frame>,
argv=<register ECX not in topmost frame>)
[/home/austin/wine-git/dlls/urlmon/tests/../../../include/wine/test.h:505] in
urlmon_test (0x0032fed8)
16 0x606a0b18 __wine_spec_exe_entry+0x88(peb=0x7ffdf000)
[/home/austin/wine-git/dlls/winecrt0/exe_entry.c:36] in urlmon_test
(0x0032ff08)
17 0x604800d0 start_process+0x130(arg=(nil))
[/home/austin/wine-git/dlls/kernel32/process.c:914] in kernel32 (0x0032ffe8)
0xaaaaaaaa: addb %al,0x0(%eax)
+relay,+seh,+tid,+wininet attached
--
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=17627
Summary: winhlp32: clickable area out of sync with hyperlink text
Product: Wine
Version: 1.1.13
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: richedit
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
[The following cannot be observed since wine-1.1.14 because of bug #17601. I
believe this makes #17601 a blocker for the present issue.]
Between wine-1.1.0 and 1.1.13, after scrolling with keyboard, the mouse
sensitive clickable areas stay at their old position, while all text has
scrolled! Also, the bottommost line of text may not be refreshed when scrolling
upwards. Similar results with PgUp and PgDn, where sometimes half the screen is
not refreshed.
OTOH, scrolling via the mouse with the wheel, the scrollbar or the 2 scrollbar
arrow buttons works.
It looks like the situation degraded over time -- perhaps several bugs are
involved -- however one issue is older than 1.0.1:
In 1.1.0, as well as 1.0.1, the synchronisation between link text and sensitive
area is mostly fine -- except when using the cursor keys on a page where all
text fits on the page. There, using the up arrow key causes scrolling up, while
the clickable areas don't move. If you click inside the window, a cursor
appears and the up/down keys cease scrolling and move this cursor instead.
To reproduce, go to a page with links that fits the window (I used winace.hlp).
The cursor shall not be visible. Hit the down cursor key. The text scrolls up,
while the mouse sensitive areas remain in place (and are functional). Click
into the window and the cursor appears. If you move up now, some text scrolls
down, but the refresh is very incomplete.
To observe the effect in 1.0.1, you need to scroll up with the down key until
after the scrollbar reaches the bottommost position: i.e. you're scrolling
farther than would be possible with only the mouse.
Obviously, the fact that 1.0.1 displays scrollbars immediately while 1.1.0
lacks them (cf. bug #14293) does not matter. So this is not the same as bug
#14293 which only appeared in 1.1.0.
--
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=17601
Summary: winhlp32: links ceased working
Product: Wine
Version: 1.1.16
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: programs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
Somewhere between 1.1.11 and 1.1.16, the (document internal) links in .hlp
files ceased working. The link is still shown in green letters, but the mouse
does not change when over it, nor is it clickable.
Git regression testing will follow ASAP.
--
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=17547
Summary: Powerpoint 2007: crashes when opening complex .pptx
files.
Product: Wine
Version: 1.1.15
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: rumirand(a)gmail.com
Created an attachment (id=19695)
--> (http://bugs.winehq.org/attachment.cgi?id=19695)
Output
Powerpoint 2007 crashes every time I try to open complex pptx files (with lots
of SmartArts, tables, various different backgrounds). With simple pptx files
and Office 97/2003 ppt files Powerpoint works ok. I attached the output and a
pptx file that shows this behavior.
--
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=17511
Summary: Keyboard producing dual events when game starts with
NumLock turned on
Product: Wine
Version: 1.1.15
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P4
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jnewl(a)socal.rr.com
When starting the game Euro Truck Simulator with NumLock on, pressing any
keyboard key ingame yields a dual event: that key's action + pause. This
renders the game basically unplayable when using the keyboard, as your
simulated truck's accelerator as well as many other important functions are
mapped to the keys.
Here's the thing: while I was scouring through the bug list looking for clues
to fix the problem, I ran across this bug: 10266, which is what gave me the
idea to look to the NumLock key for a possible solution. As it turns out,
starting the game with NumLock turned off does indeed fix the problem (turning
NumLock off while ingame, however, does not work). It seems that this may be
because the pause function is mapped to NumLock in the game, but I can't know
for sure since it's not documented. In any case, pressing NumLock ingame does
pause and unpause the game properly.
The other people who have posted results for the game give it a Platinum rating
and don't mention it behaving like this.
Anyway, as I said, there is an easy, temporary fix that makes the game
perfectly playable, which is why I gave this report a Priority 4, but without
that fix it's an exercise in futility (hence, severity Major).
(I don't understand enough about this stuff to know if I'm posting about a bug
that's been reported previously or not--the reports here tend to use technical
language--but please know that I did try to research it before posting. The
person who approved my test results at WineAppDB requested that I submit a bug
report here about it, so that's what I'm doing.)
I'm running Ubuntu 8.10 ("Intrepid Ibex") with all current updates on an AMD64
Dual Core 4600 machine w/2Gb RAM, Nvidia GeForce 8800GT, and a Saitek Eclipse
II USB keyboard. My wine install is clean, but I do have winetricks installed.
--
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=17485
Summary: Non-windows apps generate an inappropriate dialog
Product: Wine
Version: unspecified
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: vperetokin(a)gmail.com
When you tell wine to run a non-windows app, it pops ups up an error dialog
that says "Success".
Not only does this make no sense to a non-technical user, it is also amusing to
technical ones.
It should instead say "This doesn't appear to be a Windows application." or
something similar.
--
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=17384
Summary: Naval units in Civilization 4 are drawn incorrectly
Product: Wine
Version: 1.1.15
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: olelukoie(a)mail.ru
Beginning with WINE 1.1.13 and up to 1.1.15 (current) some naval units in Civ4
BTS are drawn incorrectly. Some of them are drawn with incorrect background and
some are drawn partially. See attached screenshot.
Order of units on screenshot:
row 1: Work Boat, Galley, Trireme, Caravel, Carrack, Galeon
row 2: East Indiaman, Privateer, Frigate, Ship of the Line, Ironclad, Transport
row 3: Destroyer, Battleship, Missile Cruiser, Stealth Destroyer, Submarine,
Attack Submarine, Carrier
Units drawn partially (without hulls, masts and sails - only shadows and
shrouds) are Carrack, East Indiaman and Ship of the Line.
--
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.