[HeDiBo]

'Support' wrote:

Thank you for the demo, I will check and fix it soon.

Problem solved in 13.03

[HeDiBo]

Problem fixed in 13.03

[HeDiBo]

I didn't think enough about the right solution.

This works:

Code:

procedure TsDBDateEdit.CMExit(var Message: TCMExit);
begin
if CanEdit and
( FDataLink.DataSource.State in [dsEdit, dsInsert] ) then
try
if not (csDesigning in ComponentState) and CheckOnExit then begin
CheckValidDate;
if (MaxDate 0) and (Date > MaxDate) then
Date := MaxDate
else
if (MinDate 0) and (Date < MinDate) then
Date := MinDate;
end;
FDataLink.UpdateRecord;
except
SelectAll;
if CanFocus then
SetFocus;

raise;
end;
CheckCursor;
DoExit;
end;

In other words, don't mingle with the Date if the dataset is not in Edit/Insert mode mode.

This fixed my problem completely ��

The problem occurs in your project too, if you specify a MinDate property.

[HeDiBo]

'HeDiBo' wrote:

I think the problem is the CMExit procedure, which should not assume a change in the field's data.

I made this obvious change in the TsDBDateEdit.CMExit procure:

Code:

procedure TsDBDateEdit.CMExit(var Message: TCMExit);
begin
try
if not (csDesigning in ComponentState) and CheckOnExit then begin
CheckValidDate;
if (MaxDate 0) and (Date > MaxDate) then
Date := MaxDate
else
if (MinDate 0) and (Date < MinDate) then
Date := MinDate;
end;
if FDataLink.Field.DataSet.State in [dsEdit, dsInsert] then FDataLink.UpdateRecord;
except
SelectAll;
if CanFocus then
SetFocus;

raise;
end;
CheckCursor;
DoExit;
end;

That solved the problem. But introduced another one: when selecting a field in the same record, the date field always showed the MinDate: 16-03-1928. When posting the record, that date was made permanent.

Then I changed the obvious place:

Code:

procedure TsDBDateEdit.UpdateData(Sender: TObject);
var
D: TDateTime;
begin
if not ( FDataLink.Field.DataSet.State in [dsEdit, dsInsert] ) then Exit;
ValidateEdit;
D := Self.Date;
if D 0 then
FDataLink.Field.AsDateTime := D
else
FDataLink.Field.Clear;
end;

That was a bit better. The MinDate showed, but was cleared as soon as I edited another field in that record. But I was still able to store the MinDate when posting the dataset.

So, in the end, it's a mess 😢

[HeDiBo]

'Support' wrote:

Hello!

Try this demo, please: http://www.alphaskin…mos/adbdemo.zip

Can the issue be repeated there?

Maybe type of database have influence?

It can not be repeated with your example. You are right in assuming it depends on the database type. The problem is as indicated below.

Code:

procedure TsDBDateEdit.CMExit(var Message: TCMExit);
begin
try
if not (csDesigning in ComponentState) and CheckOnExit then begin
CheckValidDate;
if (MaxDate 0) and (Date > MaxDate) then
Date := MaxDate
else
if (MinDate 0) and (Date < MinDate) then
Date := MinDate;
end;
FDataLink.UpdateRecord; // <<< Not always possible, if the dataset is not in Edit or Insert mode.
except
SelectAll;
if CanFocus then
SetFocus;

raise;
end;
CheckCursor;
DoExit;
end;

Not all databases will accept an UpdateRecord call, if the dataset is not in Edit or Insert mode.

Upon the UpdateRecord, the TsDBDateEdit does this:

Code:

procedure TsDBDateEdit.UpdateData(Sender: TObject);
var
D: TDateTime;
begin
ValidateEdit;
D := Self.Date;
if D 0 then
FDataLink.Field.AsDateTime := D // <<< Produces the database error
else
FDataLink.Field.Clear;
end;

I think the problem is the CMExit procedure, which should not assume a change in the field's data.

[HeDiBo]

Problem solved in 13.02

[HeDiBo]

'Support' wrote:

Thank you for the suggestion, I will try to add it too.

Thanks

[HeDiBo]

No change in 13.02

[HeDiBo]

'Support' wrote:

ALeft and ATop are the absolute coordinates for showing of the popup window (coordinates are not depended from AOwnerControl)

Yep. And that is strange. What is the purpose of passing an AOwnerControl if it is unused (for that you have the other implementation, passing a ALeftTop TPoint).

My change made a lot of sense, as a matter of fact, now I can use the procedure where before I had to do a lot of ClientToScreen calculations.

[HeDiBo]

'Support' wrote:

Thank you for the code.

I think to name it as MarginsPage, because margins for tabs may be added later (I mean tab areas with glyphs and captions).

I wanted such feature for a long time. I have a lot of page controls. In fact the whole application is one big page control. Using page controls inside tabs adds a lot of dead waste to the borders. I would welcome this change.

[HeDiBo]

'Support' wrote:

Hello!

Most latest skins looks better without this shifting of content.

I was looking the Windows 10 interface, many other big programs, example of design from google, adobe and some other companies.

I see that this shifting is used less and less.

I think, better solution will be to define such shift in the each skin immediately.

All skins will have own better behavior in this case.

I understand all that. But the point is that the default should not change. That's what all older projects depend on. It's not right if visuals change suddenly.

Putting it in the skin makes much more sense.

[HeDiBo]

I have another request.

I am confused about the direction the roll out arrow is pointing.

Look at this picture:

[attachment=8669:RollOutCollapsed.jpg]

I would expect the roll out to appear to the right. But it doesn't. It appears at the bottom.

After that the arrow looks like this:

[attachment=8668:RollOutCaption.jpg]

but I know already that the panel is shown below. The arrow should point up, suggesting that's where the panel goes if the arrow is clicked.

This could be governed by a simple property: DirectionArrows (boolean). True means the arrows show the direction of the panel. False: they remain as it is now.

[HeDiBo]

'Support' wrote:

You will like new icons for DBNavigator, I think 🙂

They look great

[HeDiBo]

'Support' wrote:

Old glyphs will be available in the nearest release with coloring (if ac_OldGlyphsMode is True).

If I like the new icons for Folder, Calendar, etc. but dislike the icons for the DBNavigator, I'm in a bit of a predicament.

I think different icon groups should have their own setting.

[HeDiBo]

'Support' wrote:

Old glyphs will be available in the nearest release with coloring (if ac_OldGlyphsMode is True).

[attachment=8667:DbBtns.png]

UseColoredGlyphs will work not only under latest Delphi XE, but with Delphi 5 even.

But these glyphs are raster and looks worse if scaled.

I'm planning to make the AlphaControls scalable easily and all icons should be scalable in this case.

Also, raster glyphs looks worse on the dark skins.

You're right. I wouldn't have complained if the icons looked OK, but they don't. They are too fat and large. Also the symbol for Edit is wrong. So, if you can bring the coloring back in the new setup and remodel the icons a bit (probably using a smaller font size for these symbol fonts may already do the trick) I will be very satisfied

[HeDiBo]

Also the option of colored buttons (UseColoredGlyphs) does not work anymore

[HeDiBo]

'Support' wrote:

No, there is no special options for showing of buttons at the bottom.

I understand that. I was just asking, what combination of TabSkin and other AC things you would use to make the tabs look as buttons.

[HeDiBo]

'Support' wrote:

Thank you for screenshots, I have found this difference in a code.

New release with changes will be available very soon.

Thanks.

Maybe you have a better way to show tabs as buttons on the bottom of a page control?

[HeDiBo]

'Support' wrote:

Thank you for the demo.

It' looks really ugly because section TB_BTN used as buttons in the form titlebar, this is a purpose of this section.

I think, all buttons will be ugly there because the tsTabs style used (and can't be changed). So, margins of such buttons are 0.

There was no problem with this setup in 12.22

And a lot of skins handle this properly (like Notes skins, Cappuccino, Zest, SnowLeopard, etc.)

This is how the test program looks in 12.22:

[attachment=8663:TB_BTN 1222.jpg]

Compare that to this:

[attachment=8664:TB_BTN Bug.jpg]

Something must have changed.

[HeDiBo]

'Support' wrote:

I will think about a new property in the TsSkinManager for using of old glyphs.

First of all, the variable ac_OldGlyphsMode should default to true (that's what a developer will expect: if you want a new feature, you have to specify that).

Then in sSkinManager.pas do this:

Code:

TacButtonsSupport = class(TPersistent)
private
FShowFocusRect,
FShiftContentOnClick: boolean;
public
constructor Create(AOwner: TsSkinManager);
published
property ShowFocusRect: boolean read FShowFocusRect write FShowFocusRect default True;
property ShiftContentOnClick: boolean read FShiftContentOnClick write FShiftContentOnClick default False;
property OldGlyphsMode boolean read GetOldGlyphsMode write SetOldGlyphsMode default True;
end;

In SetOldGlyphsMode, you set the ac_OldGlyphsMode variable. In GetOldGlyphsMode you retrieve it.

I think that's the simplest situation..

The property should also cover the JasonToms case. In other words, not only should the icons be colorful, they should default to the old icons.

A change to the property should result in redrawing of the combobox.

PS. I like the new look!

[Author]

Posts