[HeDiBo]

Problem solved in AC 12.08

[HeDiBo]

'Support' wrote:

Thank you for the Exe and Log files.

I think, it's strange, but calendar buttons works well in your Exe on my PC (except “Next Year” button, this button works too, but glyph is not visible).

I need more info about your Windows and Delphi versions.

Also, TsMonthCalendar works well on your side?

The TsDateEdit placed to the form directly works well?

The icon of the Next Year button is invisible. After changing the order of unit creation (datamodule first) that's the only thing that remains.

The test project that I sent you is a true mimic of my large project. So, about placement etc. that will answer all your questions.

However, this test project does not fail!. In my larger project the calendar closes as soon as a button is clicked without acting upon its intended purpose. Therefore I have sent you the message trace, which is from my actual large project.

I'm working with Windows 10 Pro (64 bit version) and with Delphi XE4.

[HeDiBo]

'Stertor' wrote:

Эта ошибка ещё с 2016-версии тянется, и сабклассинг тут ни при чём.

I think this says:

This error still runs from the 2016 version, and subclassing has nothing to do with it.

but even in English I do not know what you mean.

[HeDiBo]

'Support' wrote:

Hello

AC_NOHANDLEFORM was used for debug. If this key is enabled then Window proc of the popup form is not changed. But some features are not available in this case, such as autohidding for example).

I will try research this component more and find a cause of the exception.

Not solved in 12.07, but maybe that's too soon .

[HeDiBo]

My problem with the TsDateEdit not responding to the buttons in the calendar is still unsolved.

I made a message trace of the bug.

What I do is start the program, go to the tabsheet containing the DateEdit, click the button, click the Next Month button (which does not do a thing except close the Calendar) and stop the program.

I traced the messages in sMonthCalendar, sToolEdit, acPopupCalendar and sPopupClndr. This is the result:

[attachment=8299:alphalog.txt]

I noticed the log contains no more than two LBUTTON messages, one for button down, followed by one for button up. After that, apparently things go wrong.

[HeDiBo]

'Support' wrote:

SkinSelector is linked with SkinManager and fully synchronized with this Manager, list of available skins is fully equal now.

SkinManager is a source of this list. So, if list of available skins in Manager is limited, then this list should be limited in the SkinSelector too.

Limiting the skins in SkinSelector to skins available in SkinManager is totally acceptable. I didn't expect anything else.

But SkinSelector for the user is the window fo the skins in SkinManager (which is further unknown to the user). By user I mean the end user of the program.

The choice from all available skins in SkinManager could be limited to a number of criteria: only dark skins, only free skins, only internal skins. I was suggesting the latter, but thinking about it, it is simply:

SkinSelector offers a choice of skins from SkinManager; this choice may be limited to certain skin criteria, internal skins being one of them.

[HeDiBo]

Making the datamodule first solved the problem of the title bar. Thank you.

The “next year” button problem remained though.

[HeDiBo]

'Support' wrote:

Thank you for the demo.

Can you give me your Exe also? I will check it on my system.

By the way, Datamodule with SkinManager is created after the form creation in this project.

I always suggests to create DataModule before all forms.

I will try that.

Here is the exe:

[attachment=8294:acDateEditBug.zip]

[HeDiBo]

'Support' wrote:

Do you mean, indexing of properties with equal setters or getters is a bad idea? Why this code is not incomprehensible?

Maybe if the index would have symbolic names, it would be better.

But this was only an example.

In general the code should be so easy to read, that a manual would be superfluous. That would accomplish two things: a very maintainable source code and a very good reference text for your users. As it is now, all efforts are made to shrink the source code. I even saw this in the transition of 12.06 to 12.07:

Code:

.
.
else
inherited;
.
.

was changed into

Code:

.
.
else inherited;
.
.

Why? Do you really think the latter is more readable? I give it to you that readability of the source code was never a goal. However, my many years of experience taught me that readability is the prerequisite for maintainability.

Don't get me wrong. I love AC. It's because I want it to be most successful that I take the time for such critics.

Keep up the good work

[HeDiBo]

'HeDiBo' wrote:

In principle, this is a good solution, but the TsWebBrowser component will show a horizontal scroll bar if the HTML text does not fit the window.

It should not do that, in fact it should almost never do that, because the text should be wrapped.

It's almost impossible to get rid of the horizontal scroll bar.

Setting SkinData.HorzScrollData.ScrollWidth to 0 will do the trick. But that would disable the horizontal scroll bar for all content.

[HeDiBo]

'Support' wrote:

Thank you

I can suggest you to hide this control in the document body style:

Code:

I can't remove this scroll by delphi code, unfortunately, because it's drawn in the document and I have no idea how to do it currently.

In principle, this is a good solution, but the TsWebBrowser component will show a horizontal scroll bar if the HTML text does not fit the window.

It should not do that, in fact it should almost never do that, because the text should be wrapped.

It's almost impossible to get rid of the horizontal scroll bar.

To illustrate, this is the same demo project, but with the suggested addition of disabling the vertical scroll bar:

[attachment=8260:acWebBrowseScroll.zip]

Try to get rid of the horizontal scroll bar.

[HeDiBo]

'Support' wrote:

Thank you

I can suggest you to hide this control in the document body style:

Code:

I can't remove this scroll by delphi code, unfortunately, because it's drawn in the document and I have no idea how to do it currently.

This comment should go to the TroubleShooting forum, where you have a topic with this same project as a demo for the bug.

[HeDiBo]

'Support' wrote:

You can remove 1 topic, I think…

The topic you're referring to is an offer to include the code into one of the upcoming releases of AC.

The same code is used here to show a bug in the TsWebBrowser component.

So both topics serve their own purpose.

[HeDiBo]

'Support' wrote:

This property will be available in the v12.06

Fantastic

[HeDiBo]

'Support' wrote:

Described feature will be implemented in the v12.06

Really great

[HeDiBo]

'Support' wrote:

I'm sorry, I can't compile the demo. The 'Common' doesn't exists.

You probably already found the correct version:

http://www.alphaskins.com/forum/index.php?showtopic=9513&st=0#entry50100

[HeDiBo]

'Support' wrote:

Hello

The 'common' unit doesn't exists and ColorToHTML is not found…

I'm very sorry, I sent the wrong version.

Here is the correct version:

[attachment=8253:ShowHelp.zip]

[HeDiBo]

I'm sorry, I still think the icon is not clear enough. In this case, it is a bit too small. And it doesn't look like a button, although it's the only clickable object in the control.

Maybe you can have another look at it?

[HeDiBo]

'Support' wrote:

I will try to improve a painting of the TsDBEdit placed on TsDBCtrlGrid in the nearest release.

In AC 12.05 it's great now

[HeDiBo]

Problem still exists in AC 12.05

[Author]

Posts