[HeDiBo]

'Support' wrote:

Thank you for the demo. Interesting situation.

I think, panel should be hidden if not focused or if mouse is not hovered there…

But panel is visible after form showing. Maybe this panel must be hidden if not focused after showing?

I don't understand what you mean. Think again. As it is now it's not possible to have a TsDateEdit field in a roll out panel with auto hiding.

[HeDiBo]

'Support' wrote:

Hello!

I meant that Collapsed state may be defined before OnCreate event (when properties are loaded from Dfm).

If panel was expanded before OnCreate event, then OnAfterExpand will not be called…

I consider OnAfterCollapse and OnAfterExpand to be events that are the result of some user action. If the roll out panel is expanded in the dfm, than it's very easy for a programmer to implement in the FormCreate event allocation of the resources needed for the panel (test if Collapsed state is False).

[HeDiBo]

'Support' wrote:

You are right, I will change it in the nearest release.

The sSkinProvider module has the same problem:

Code:

procedure TsSkinProvider.OnHintTimer(Sender: TObject);
begin
if (FHintTimer nil) and (FHintTimer.Tag 0) then begin
FHintTimer.Enabled := False;
if PtInRect(FHintRect, acMousePos) then
ShowHintWnd(TacTitleBarItem(FHintTimer.Tag)); // This causes trouble
end;
end;

Making a similar change as in TacFloatBtn, solved this problem too.

[HeDiBo]

I found out how to write HTML that shows Font Awesome special characters:

Code:

body {
font-family: “Trebuchet MS”;
}
#faw {
font-family: “Font Awesome 5 Free Solid”;
vertical-align: -10%;
}

This is the heading

This  is the next sign.

This will work, if the font is installed on the system.

In my application I implemented the font through a TsFontStore component. Now it will work if I use the font in my regular program. However, if I use this text in a TsWebBrowser, the font is not usable (unless of course it is installed in the system).

I'm not sure if this has something to do with the font being local to a process and the web browser operating in a separate process.

How can I let the web browser know also about the font. And the print server as well, because my web pages all are printable.

Maybe TsFontStore needs an augmentation to make some fonts known system wide?

[HeDiBo]

You're implementation of DimUnacceptedCells is perfect 👌

[HeDiBo]

'Support' wrote:

What to do if Collapsed state is not changed after OnCreate event?

It's possible if property value is loaded from Dfm before OnCreate.

I'm not sure what the problem is.

If the Collapsed state is not changed, then naturally there should be no OnAfterCollapse event. (OnAfterExpand may be another matter, because one may allocate resources needed for the expanded panel, like I show in the sample project, but again, that in fact rules out the OnAfterCollapse event, which otherwise might free resources that were never allocated).

If you think there should be an event to indicate the state (Collapsed or not) you might consider implementing an additional OnChanged event.

[HeDiBo]

'Support' wrote:

Thank you for the example.

This issue will be solved in the nearest release, event will be called once only.

I hope that will be after the OnCreate of the containing form

[HeDiBo]

'Support' wrote:

Hello!

Can you help me to repeat this error in the test-application? Is it possible?

Your code uses a Tag (which is a NativeInt) as a pointer to a TObject (which is 64 bits Word in the Win64 binary).

That's what's wrong, I think.

But my problem is only reproducable if the object resides at an address that requires more than 63 bits and has the sign set.

By the way, my solution works, I implemented it in the appropriate places in AC and got rid of the problem.

[HeDiBo]

Redefining the hint timer as this:

Code:

TsTimer = class(TTimer)
protected
FOwner: TObject;
end{class};

and making the appropriate adjustments in TacFloatBtn.pas, replacing the use of the Tag property with the FOwner property will do the trick.

The same problem could arise in procedure TsSkinProvider.StartHintTimer(TitleItem: TacTitleBarItem);

[HeDiBo]

I updated the project, to show the language and country also.

[HeDiBo]

'Support' wrote:

Hello!

LongDateFormat doesn't looks good in some other languages (russian and ukrainian are not Ok there).

You're absolutely right. So, today I digged deep into internationalization and came up with this idea: eliminate the dddd from the LongDateFormat and use the new format in a FormatDateTime call.

I made a proof of concept. Only the Mongolian long date format does not work, so in that case I translate it to short date format.

The key to it all is the

function DropDayName(const fmtDateStr: String): String;

which takes a LongDateFormat as parameter and returns a date format where the dddd day name is eliminated.

If you press the ShowAll button it lists a table of formats and results for all language ID's from 1 to 255.

With the Locale ID spin edit you can enter any Locale ID you want to test, showing the results in the four fields to the right.

Error 87 is an invalid locale ID.

The updated project is attached below.

[HeDiBo]

'Support' wrote:

I think, resource number should not be changed in the future, but this code may be patched easily if future Windows will use other numbers in the resource table.

And using of fixed number is much faster than searching seems.

Thanks 🌻

[HeDiBo]

'HeDiBo' wrote:

When scrolling by month/year the calendar flickers. First it is painted undimmed and immediately after that it is repainted with dimmed cells. This shows as a slight flicker.

This was a misinterpretation of my part. You can forget about this.

The issues that the Enter key may return an unexpected date and that the property DimUnacceptedCells should default to False are still open.

[HeDiBo]

'Support' wrote:

The FindResourceEx function doesn't work under WIndows 7 sometimes also, seems.I will research it and I hope to find a better solution soon.

You seem to have fixed it good in AC 13.16

I saw you used this piece of code to get at the localized name for New Folder:

Code:

LoadString(FindResourceHInstance(shell_handle),
16859, Buffer, Length(Buffer)))

Are you sure the value 16859 will stay the same over new Windows versions?

[HeDiBo]

It works fine now

[HeDiBo]

The property TravellingSelection works very well. Thank you

There's one aspect that does not work as requested: if the calendar is scrolled to another month/year with TavellingSelection = False, pressing the Enter key still returns the (now invisible) selected date. The Enter key should do nothing in this case, to prevent entering a date that was not meant to be selected.

The property DimUnacceptedCells works fine, but the default should probably be False, because that's the way it worked previously.

When scrolling by month/year the calendar flickers. First it is painted undimmed and immediately after that it is repainted with dimmed cells. This shows as a slight flicker.

[HeDiBo]

In AC 13.16 you have replaced the month in letters by a short date format. That's a pity, because using the month in letters looks much better.

That's why I proposed the change in the way I did. It's language independent (provided the weekday name comes first in the format, which is universally true, I think)

Maybe the TranslateDateFormat function (in XE that's FormatSettings.TranslateDateFormat) could be a universal solution for displaying month in letters and day of the month and the year. I'm not sure how it actually works. Also it's a private class function, so some meddling is necessary.

[HeDiBo]

I think this would be a good replacement:

Code:

//FTodayBtn.Caption := s_Today + FormatDateTime(' mmmm d, yyyy', Date); (*** DB ***)
ds := FormatDateTime(FormatSettings.LongDateFormat, Date ); (*** DB ***)
FTodayBtn.Caption := s_Today + Copy(ds, Pos(' ', ds), 9999); (*** DB ***)

[HeDiBo]

To disable showing the selection, first of all, the property ShowSelectAlways of the popup month calendar should be settable in TsDateEdit too (a very simple change).

However, in a TsMonthCalendar I could not make the property ShowSelectAlways to work. Setting it to False did not change the wanted behavior of the calendar. All it did was not show a selection if no cell was clicked before scrolling a month or a year. After a cell was clicked, it was impossible to make the selection box disappear.

The problem is fundamental. You consider a selection to be made on a day of a month. But normally a user would select only one specific date. When starting to scroll, that selection should not travel to the newly shown month. Scrolling is just a way of looking at another place. It is not a way to travel there too. The selection should stay on the date clicked, not on a new, more or less random date shown.

So, I propose a new property: TravellingSelection that defaults to True (for compatibility). If it's False, a selection stays on the cell clicked, no matter where the user scrolls to. It should stay there until another cell is clicked. The Enter key should not return the selected date, if that month is not shown. If it would, the user would be in trouble if he/she would not notice this (to circumvent that pressing Enter in September could result in a date in Februari).

The new property TravellingSelection should be exported to the TsDateEdit control too.

[HeDiBo]

'Support' wrote:

The OnGetCellParams event has a constant list of parameters which can't be changed because existing projects will have a problem with compatibility in this case.

The OnAcceptDate event occurs after a clicking and allows to disable an accepting of the custom date.

I think, will be better solution to call the “OnAcceptDate” event twice – before painting of cell and after clicking.

Cells may be marked as unallowed in this case… How you think?

I've done it as follows:

Code:

procedure TFr_Planner.deDateStartGetCellParams( Sender: TObject;
Date: TDateTime;
AFont: TFont;
var Background: TColor );
var
Accepted: Boolean;
begin
deDateStartAcceptDate( Sender, Date, Accepted ); // Call the OnAcceptDate event
if Accepted then Exit;
AFont.Style := [];
AFont.Color := SysColorToSkin(clGrayText, sFrameAdapter1.SkinData.SkinManager);
BackGround := SysColorToSkin(clBtnShadow, sFrameAdapter1.SkinData.SkinManager);
end;

The font and background setting could have been an optional part of de TsDateEdit control.

One possible implementation is a property DimUnacceptedCells. Paint the cell as above upon receiving Accepted = False in the OnAcceptDate event. No change in parameters for OnGetCellParams

[Author]

Posts