[Bug 10873] New: Various display issues in/with Delphi
wine-bugs at winehq.org
wine-bugs at winehq.org
Sun Dec 23 11:30:40 CST 2007
Summary: Various display issues in/with Delphi
AssignedTo: wine-bugs at winehq.org
ReportedBy: ionic at ionic.de
Created an attachment (id=9765)
Font size set to 12 in Delphi/WINE.
after the installation of Delphi worked without noteworthy problems, I am now
experiencing a couple of issues with WINE drawing/printing things, which might
be easily fixable due to the fact that they are just graphical problems.
First one: in Delphi one can set various font sizes for elements like Labels,
Panel and so on, which works fine in Windows. But WINE shows a strange behavior
here: when changing from font size 12 to 14 WINE does nothing, whereas in
Windows the font size really grows. Also, you could set the the size to 100 (I
did for testing purposes in the screenshots), but WINE does not change any size
but uses still the 12pt size, it seems that something is broken there within
Well that's happening in the "designer" mode, but it seems to be the same on
runtime, so I guess there might be also other applications hitting that bug
with binary programs (Screenshots flagged with "Runtime") ...
Second one: properties changed in the object inspector should be bold when they
are not set to the default value. That's a nice feature which helps people to
see which property *they* changed and makes it easy to revert bad decisions.
However, WINE does not print them in bold font or anything
This bug is not limited to object inspector though, NO fonts in Delphi's
"design" mode are bold, even when set to that, but instead WINE ignores it,
even in the compiled program later on.
This does NOT hit the editor in Delphi which is able to show wonderful bold
You can find plenty examples for this bug in the "Delphi-Size-xx" screenshots.
Third issue: that is a little bit more complicated indeed and might not be
easily to fix in contrast to the first ones.
As you may or may not know (at least you will see it) Delphi has something like
a box with verbose compiler messages at the bottom side of the editor.
Now one can double click on the first message and the editor is jumping to that
specific line where an error or a warning occured, setting the background of
that line to red for better visibility.
We fix that issue (or not ;)) and double click on the second entry in that
box... this time the editor should jump to the second error line and so on,
like above, but there are some problems with WINE.
When clicking on the second entry the editor is NOT jumping to the second
erratic line but to the first one and the first entry remains
"activated"/highlighted in that box.
It is possible to override/"fix" that behavior by clicking into that box one
time and then selecting the entry one wants to have a closer look at and THAN
double click on it/in the box.
Well, as that might be possible, it's not very comfortable and not the default
behavior and should be fixed as well. :)
So that are my three points so far, I could not find any other bugs yet. ;)
You will have some screenshots attached both with WINEs (version 0.9.51 with
that little msi patch of truiken) behavior and the one under a natively running
Windows (not on the same boxes, though, but that should not cause any problems)
in the next comment. (By the way, why does Bugzilla allow only one attachment
in the first Bug Commit?)
(The entries in the StringGrid you see there in two of the screenshots are just
plain fiction; neither the names nor the attributes given there correspond to
the reality. (I included this to prevent privacy legality actions.))
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs