[Iruau]

Hi,

While I was at it I also modified a few strings that I didn't notice the first time :

CODE

Index: sStrings.rc
===================================================================
— sStrings.rc    (revision 255)
+++ sStrings.rc    (working copy)
@@ -14,7 +14,7 @@
   s_MsgDlgHelpNone, “Pas d'aide”
   s_MsgDlgHelpHelp, “Aide”
   s_MsgDlgAbort, “&Abandonner”
–  s_MsgDlgRetry, “&Retenter”
+  s_MsgDlgRetry, “&Réessayer”
   s_MsgDlgIgnore, “&Ignorer”
   s_MsgDlgAll, “&Tous”
   s_MsgDlgNoToAll, “N&on à tous”
@@ -23,17 +23,17 @@
   s_RestoreStr, “Restaurer”
   s_MoveStr, “Déplacer”
   s_SizeStr, “Taille”
–  s_MinimizeStr, “Minimiser”
–  s_MaximizeStr, “Maximiser”
+  s_MinimizeStr, “Réduire”
+  s_MaximizeStr, “Agrandir”
   s_CloseStr, “Fermer”

   s_HintClose, “Fermer”
–  s_HintMaximize, “Maximiser”
–  s_HintMinimize, “Minimiser”
+  s_HintMaximize, “Agrandir”
+  s_HintMinimize, “Réduire”
   s_HintRestore, “Restaurer”
   s_HintHelp, “Aide”

–  s_FileOpen, “Ouvrir fichier”
+  s_FileOpen, “Ouvrir le fichier”

   s_Calculator, “Calculer”
   s_GradBuilder, “&Éditeur de dégradé…”
@@ -93,7 +93,7 @@
   s_Folder, “Dossier”
   s_FileName, “Nom du fichier”
   s_FileType, “Type de fichier”
–  s_ReadOnly, “Lecture seul”
+  s_ReadOnly, “Lecture seule”
   s_ViewStyleList, “Liste”
   s_ViewStyleReport, “Détails”
   s_ViewStyleIcons, “Icônes”

And by the way, recompiling the .res file didn't work out of the box : somewhere between versions 6.45 (excluded) and 6.58 (included), a bunch of identifiers disappeared from sStrings.pas but the .rc files still have a reference to those. I took the easy (lazy) way and just checked out sStrings.pas version 6.45 from my own SVN, but I guess this is not ideal (all the .rc files should be updated by deleting the now useless identifiers/translations). Anyway, here are the corrected French resources, coherent with the other translations (ie. including the now missing identifiers) :
[attachment=3970:Res_French.zip]

Keep up the good work!

[Iruau]

Whoops, sorry I didn't see Serge's message until now.

in reply to: Packaging application-specific glyphs in the skin file? #42273

[Iruau]

Thank you very much for the demo Serge, this is exactly what I need ! Perfect.

Have a nice day and keep up the good work.

[Iruau]

Hi,

I'm still stuck on this. Your solution gives me a raw bitmap, so I have to recombine the alpha mask by myself which isn't quite satisfying. Moreover, it doesn't benefit from ASkin's capability to use borders (so that the glyph is extensible), textures and what not, which would be a really neat feature to add to the glyphs. Anyway I also need those features for other uses.

And when it comes to my own solution that I already posted, it has a serious drawback : it *needs* a background color, but I want the resulting bitmap to have alpha transparency (ie. “background” color is transparent) which I can't achieve.

In other words, I'm trying to find a way to do something as simple as CreateAlphaBitmap32OrPngFromSkin(skinManager, skinSection, state, sizeX, sizeY, destinationBitmap).

Any ideas ?

[Iruau]

Thanks Serge, I will try that.

[Iruau]

Ok, I finally figured out how to achieve that.

1) Obviously, define a new section for a specific glyph
2) Code (it's C++ but you Delphi people should have no problems to port it):

CODE

// imgList is a TsAlphaImageList
imgList->AcBeginUpdate();
imgList->Clear();
imgList->Items->Clear();

// For each glyph…
std::auto_ptr bmp(sGraphUtils::CreateBmp32(imgList->Width,imgList->Height));
sGraphUtils::PaintSection(bmp.get(),”MY_GLYPH_SECTION”,””,0,skinProvider->SkinData->SkinManager,TPoint(0,0),SomeColor);
imgList->Add(bmp.get(),0);
bmp.reset();

imgList->AcEndUpdate();

Maybe there is a more efficient way, but at least that works.

[Iruau]

QUOTE (Support @ Mar 11 2010, 12:45 PM) <{POST_SNAPBACK}>

Yes, it's in plans already, but I can't say now when this feature will be implemented (not soon, I think).

Ok, thanks for the info. If I may give you a few suggestions about that…

Perhaps it would be a good idea, as a first step before full implementation, to allow editing fonts in the SkinEditor and some ASkin API to read those values, even if the controls themselves are not automatically using the defined fonts. This will allow us programmers to have this information in the skin, and even if we must write specific code to apply the fonts to the controls, that's better than nothing. Plus, I believe this would be relatively easy for you as this requires much less work than a full implementation. I for one would be perfectly happy with such a solution.

I think a good idea would be to allow font “cascades”, like the font-family property in CSS : if “font 1” is available then use it, else use “font 2” if possible, else “font 3” etc etc.
Except that a cascade just on a font family is a bad idea I think, because some fonts require very different sizes to display at the same perceived size (I have this kind of problem on certain web pages, this restricts the fonts I can use in the same cascade). So at final that would be more like : use in priority “font 1” at size X, or “font 2” at size Y etc etc.

Also, if a font property is left undefined in a skin section, just use the parent control's font, or the global font as a fallback if there is no parent (for forms / dialog boxes etc). Maybe the possibility to define relative sizes too (like, “section X” font is the same as parent, but 150% size) ?

I believe such complex font selection can easily be wrapped in a single runtime method, like “DetermineFontAndSize(Section, optional ParentControl)” (sorry, I suck at Delphi so I don't know the actual syntax, I'm a C++ programmer

in reply to: Adding custom colors and fonts that are editable in SkinEditor #41869

[Iruau]

QUOTE (Support @ Mar 11 2010, 11:59 AM) <{POST_SNAPBACK}>

You can add several own skinsections for these purposes and use them, why not?

After thinking a bit more about it, I guess I will just duplicate sections according to their role in my application (like, “LABEL_ERROR” etc). I think this will do the trick.

QUOTE (Support @ Mar 11 2010, 11:59 AM) <{POST_SNAPBACK}>

Also remember please that you can change colors of controls directly if SkinData.Custom color is True.

Yes, that's what I'm currently doing but hardcoded colors can be problematic depending on the skin (contrast problems etc), so I want to give the user a full control over that, so the best/easiest solution (both for me and the users) is to include those colors in the skin file.

QUOTE (Support @ Mar 11 2010, 11:59 AM) <{POST_SNAPBACK}>

(but font face and sizes can't be stored in a skin)

Awwww… Do you (or anyone else on this board) have any idea how I could work around that limitation ?
If this is not possible at all, well, I believe that would be a great enhancement to ASkin… (unless there are very good reasons not to do so?)

[Iruau]

I second that idea wholeheartedly. It would be very handy.

[Iruau]

See the documentation for AddObject method.
You will have to reinterpret_cast (this is C++, sorry I don't know the equivalent in Delphi) the TObject* pointer into your datatype.

If the value you need to store is <= 32 bits then all is fine, otherwise you will have to manage dynamic (de)allocation (in which case it may be easier to maintain a separate array like Sergei explained).

[Iruau]

I'm confirming that this solves the problem.

Thank you very much for working around TntUnicode bugs again !
Keep up the good work.

[Iruau]

QUOTE (Support @ Oct 7 2009, 11:03 AM) <{POST_SNAPBACK}>

Could you give me a little demo with problem?

Here you go…

DFM :
Please note that I removed any internal skin before copy/pasting the code (for size reasons). Don't forget to add a skin and set the skin manager to Active=true before testing the project. The problem appears whether the window is maximized or it is too near the right edge of the screen, regardless of the chosen skin.

CODE

object wndMain: TwndMain
  Left = 419
  Top = 231
  Width = 403
  Height = 257
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object skinProvider: TsSkinProvider
    SkinData.SkinManager = skinManager
    SkinData.SkinSection = 'FORM'
    TitleButtons = <
      item
        Hint = 'Some very long hint that overlaps the screen edge'
        Name = 'TsTitleButton'
      end>
    Left = 112
    Top = 56
  end
  object skinManager: TsSkinManager
    Active = False
    InternalSkins = <>
    MenuSupport.IcoLineSkin = 'ICOLINE'
    MenuSupport.ExtraLineFont.Charset = DEFAULT_CHARSET
    MenuSupport.ExtraLineFont.Color = clWindowText
    MenuSupport.ExtraLineFont.Height = -11
    MenuSupport.ExtraLineFont.Name = 'MS Sans Serif'
    MenuSupport.ExtraLineFont.Style = []
    SkinInfo = 'N/A'
    ThirdParty.ThirdEdits = ' '
    ThirdParty.ThirdButtons = 'TButton'
    ThirdParty.ThirdBitBtns = ' '
    ThirdParty.ThirdCheckBoxes = ' '
    ThirdParty.ThirdGroupBoxes = ' '
    ThirdParty.ThirdListViews = ' '
    ThirdParty.ThirdPanels = ' '
    ThirdParty.ThirdGrids = ' '
    ThirdParty.ThirdTreeViews = ' '
    ThirdParty.ThirdComboBoxes = ' '
    ThirdParty.ThirdWWEdits = ' '
    ThirdParty.ThirdVirtualTrees = ' '
    ThirdParty.ThirdGridEh = ' '
    ThirdParty.ThirdPageControl = ' '
    ThirdParty.ThirdTabControl = ' '
    ThirdParty.ThirdToolBar = ' '
    ThirdParty.ThirdStatusBar = ' '
    ThirdParty.ThirdSpeedButton = ' '
    Left = 144
    Top = 56
  end
end

Additional info : I'm using Borland C++Builder 6 / ASkin 6.45 / TntUnicode 1.7.0.3 under Windows XP SP3.
The TwndMain form is an instance of TTntForm.

[Iruau]

Hi,

I just installed v6.45 stable, and unfortunately the problem is still here after a full rebuild of my project.

Granted it's better than with v6.44 (I can see more of the hint text) but it's still not solved.
I guess correct behaviour would be to align the right side of the hint window with the right edge of the screen.

[Iruau]

Now works fine in 6.41. Thanks.

[Iruau]

Thanks.

EDIT: Fixed in 6.41. Thanks for the fast job.

[Iruau]

When compiling 6.32 / 6.40 with TNTUNICODE enabled, there is a problem with SystemParametersInfoW : for an unknown reason it returns a bad value for lfCaptionFont.lfHeight, which makes the title font too big for me (BCB6 + ASkin 6.40 + TNT).

I found that using SystemParametersInfo instead of SystemParametersInfoW solves the problem (so there is no need of the TNTUNICODE compiler switch here).
Also, I see no compelling reason to use the W API here because you use only numerical results. Granted, the A and W APIs should theoretically return the same values but in practice they don't, at least in my environment, so I decided to use the correct one and share that with you.

[Iruau]

For the record, I managed to work around that problem by reverting procedure GetCaptionFontSize in acntUtils.pas to the 6.20 version (removing the {$IFDEF TNTUNICODE} part):

CODE

function GetCaptionFontSize : integer;
var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(NonClientMetrics);
  if SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0) then
    Result := NonClientMetrics.lfCaptionFont.lfHeight;
  else
    Result := 0;
end;

Seems to work fine so far.

[Iruau]

Hi,

It also happens with TsPathDialog, but it doesn't happen in ASkinDemo.exe.

And yes, I use TntUnicode (1.7.0), with Borland C++Builder 6 (same compiler as Delphi 6 I think).

Thanks again.

[Iruau]

Hi,

The skinned caption font is indeed the same as the system font (Tahoma on WinXP).

Thanks for your time.

[Author]

Posts