Forum Replies Created
-
Posts
-
'Support' wrote:
If you have a time you can check this issue in the my original ASkinDemo.exe: http://www.alphaskin…s/askindemo.zip
MonthCalendar may be found at the last frame there (“Unsorted”).
We will know, this behavior is depended from compiler or from OS.
I have tested it now under Win 7 and Win 10, result is same, test works Ok with this error.
Tried it (i ran the exe directly from your zip file), got the same bug (I'm on Windows 10 Pro).
'Support' wrote:Could you show a screenshot with bad focus rectangle, please?
If you run the acSetFocus project, I included, after some tabbing you will end up with this: [attachment=8838:FocusCheckBox.jpg]
Try to find where the focus is.
The problem is that check boxes without a caption are not highlighted.
The skin should be changed, to highlight the check box itself, not its possible caption.
'Support' wrote:But in all my tests these two variables has equal value, this is a reason why tests were Ok.
This is strange indeed.
Apparantly in some cases, the format string changes to the result
'Support' wrote:Thank you, I will research it.
Despite your efforts, the date string is broken now. It says: “d MMMM yyyy” for today. I wish you would test your source before releasing it.
The last statement in sDateUtils.DateToLongStr should read “Result := sf;” i.s.o. “Result := s”.
In AC 13.17 the combobox now shows a focus rectangle
But the checkboxes only show a faint line at the right hand side. A full focus rectangle was what you intended, I understood. Maybe you can reexamine the source for this.
There are skins that do not need the focus rectangle. Look at Material Dark, who lights up the surrounding square in a contrasting color. A focus rectangle there would be overkill.
In other words, maybe the skins need some change.
You changed the default for DimUnacceptedCells. This may be unexpected for some. A warning about this should have been in the release notes.
The number of event calls has been reduced to one in AC 13.17
However, the OnAfterCollapse event still occurs if the Collapsed property is True. As I said, that precludes freeing up resources that were allocated in the OnAfterExpand event. If Collapsed would be the default property, the OnAfterCollapse event could be suppressed when reading the dfm, isn't it?
I have some bad news.
My font program doesn't work at all in Windows XP for otf fonts. Apparently, we need a totally different approach altogether.
I've included the NexusFont utility: [attachment=8832:Nexus Font Portable Version 2.6.2.zip]. No matter what system and no matter what font (otf or ttf) it will always retrieve the right properties. Might be interesting to test that on your crooked fonts. It might even allow you to install these fonts in Windows 7.
Unfortunately, although it's free, it's not open source. We cannot have a peek at how this implementation works.
This is his site: http://www.xiles.net/
'Support' wrote:I have downloaded and runned this update, but I have received that update can't be applied on my system.
I can't say why it can't installed, my system Win7 x64, update file name is “Windows6.1-KB2753842-v2-x64.msu”
I think, I will add a special warning label for developers in the design-time editor, but support of OTF will not be added in the nearest release.
Latest release will be uploaded today-tomorrow.
Have you checked in installed updates, whether the update KB2753842 was already installed?
If not, don't you think that your system has developed a problem? Maybe it should not be used then for system critical applications?
Do you have the possibility to try the questionable fonts on another Windows 7 system with the KB2753842 applied?
In the meantime I'll try the test program on a very very old Windows XP system, using your problematic fonts. But this takes some time, even starting it up takes several minutes.
'Support' wrote:Thank you.
I'm thinking now: if developer uses Otf font in the project, he will not have guarantee for correct work of the font in all users systems.
What to do in this case? I can't find a good universal solution.
It depends a bit on how TsFontStore works. If one of your troublesome fonts is added to the TsFontStore in Windows 10, how does is work in your Windows 7 system?
By the way, anybody knows that exotic fonts can only be used if tested thoroughly. You cannot prevent a programmer's stupidity.
Also, did you try the bug fixes that I found for otf fonts in Windows 7. If they work, you could alert when TsFontStore is used, that the program will only work in Windows 7/8 if certain Windows 7/8 patches are applied. There exists no universal solution for buggy Windows versions. So, I wouldn't look for any.
This is the final version of the Font Info project: [attachment=8820:GetPrivateFontInfo.zip].
The family name is now retrieved from the LogFont structure, which can be obtained with the undocumented but always present GetFontResourceInfoW Gdi32 call
The properties from the LogFont structure are also listed.
The MSDN description of LogFont shows the meaning of the different values.
Apparently the problem with OTF fonts and Windows 7 or 8 has something to do with Microsoft Security Update KB2753842:
I completed the test program: [attachment=8819:GetSystemFontInfo.zip]
It will now show both the font name and the family name of the font file.
For this I used the undocumented gdi32 call GetFontResourceInfoW. Although it is undocumented, it is already part of the gdi32 dll since Windows 98.
A good piece of description for this call can be found here: http://www.undocprin…ontresourceinfo
I found this article: http://www.tomshardw…-opentype-fonts
It shows how to relieve font problems in Windows 7, that may be related to the graphics card.
This was also very interesting: https://www.sevenforums.com/general-discussion/65308-opentype-fonts-otf-not-valid-font-2.html
'Support' wrote:All TTF fonts works well.
Some OTF fonts works, but some OTF fonts are broken under Win 7.
All OTF fonts works well under Win 10.
Then we don't have a problem have we?
You should not use the TsCharImageList with fonts you cannot read. That's obvious.
Maybe we can determine if a font will not work in windows 7 and below. So that using such a font in TsCharImageList will cause problems later on and an appropriate warning could be given.
But on the other hand, if the character image from the font does not need the actual font anymore, there's no problem at all.
