I believe you can still have a notebook without the tabs. What was changed was that instead of having a totally separate class for a tabbed notebook it used the same class but has a flag to either use tabs or not to use tabs. The thought was to consolidate the features into just one class.

Hi,

In Delphi (3) TButton is part of the stdctrls unit, in LCL it is in the buttons unit. Shouldn't it be in the strdctrls unit?

Vincent

I agree with this. As long as there is some way of mapping units (ie remaining
unit compatability with exisiting delphi prorgam) then there is no issue here..

AMC Enterprises P/L - Andrew Bednarz
First Floor - Senior Programmer
3 Chesterville Rd -
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Others should probably be broken out to units that make more sense too. But nobody has taken that task on so far and we haven't really discussed it that much before now (that I remember).

Actually, I think it was meant to be the permanent solution because I originally created them as they are in Delphi. I had created a TTabbedNotebook with tabs and the TNotebook without tabs. But someone removed TTabbedNotebook and added tabs to TNotebook. So basically that original way was removed.

I agree. Those classes should probably be broken out into units that make more sense too. I just don't think anyone has taken on the task to do this, or to discuss it. So it remained as it is.

The problem with trying to keep them as Delphi has them is that Borland could change at any time and then we would also need to change the LCL in order to remain compatible. This could cause us a lot of problems. If we have our own naming scheme, then we are in control of when it changes. Then it is just a matter of mapping our units to the Borland units somehow. This mapping could be done in properties, a config file, XML or something that is easier to change.

Curtis

I agree and have been vocal about this from the beginning. I think that Delphi should be the pattern we follow but it doesn't need to match it to the exact letter. The idea of being able to port Delphi code isn't so that it can always work in BOTH Lazarus and Delphi at the same time. It is to ease the porting to Lazarus. We would expect that once you port a Delphi application to Lazarus you would continue to use the ported version in Lazarus for Linux AND Windows. Why continue to use Delphi if Lazarus allows you to perform the same thing in both platforms without any more porting.

Now of course there are going to be ALOT of Delphi snippets that just will not port in the near future and will require the developer to continue to use Delphi. I'm thinking of things like OCX, ActiveX or whatever Microsoft wants to call them this week. :-)

But if you are using those thing they will never port directly to Linux anyway so the need for the exact porting of Delphi when using those types of things is meaningless.

D5 too ;)
for unit compatibility we should probably follow the VCL

AMC Enterprises P/L - Andrew Bednarz
First Floor - Senior Programmer
3 Chesterville Rd -
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

I have the same opinion. I think Lazarus is not just for Windows anymore, so I'd leave the units as they are.

Michal Bukovjan

Vincent Snijders wrote

Hi, In Delphi (3) TButton is part of the stdctrls unit, in LCL it is in the buttons unit. Shouldn't it be in the strdctrls unit?

In D4 as well, I think it should. Any comments ?

Marc

Just my 2c on this (below)... I really find the
notebook useful for things like wizards (eg.
InstallShield) where you don't actually want tabs. I do think it should be restored to the original
behaviour.

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

I think in the past we decided that everything doesn't have to be exactly the same as Delphi, but if it isn't, then we need to document it so that we can make Lazarus do the conversions. That is how TNotebook is. The TNotebook control in Delphi does not have tabs but the LCL one does. Also, we don't have a TTabbedNotebook any more as Delphi does.

So I don't see a problem with having buttons in a different unit. It is easier to determine where buttons are that way. The stdctrls name isn't really very helpful in determining what is in that unit. The reason Borland named it that is because those are standard Windows controls and a lot of developers prior to Delphi knew them that way. But since Lazarus isn't built just for Windows, some of those names don't make a lot of sense. Under Linux, the name stdctrls really doesn't mean anything useful, other than compatibility with Delphi. I vote to leave buttons in the buttons unit for ease of maintainability.

Curtis

Isn't it better to make something better than Delphi? There are going to be porting issues, no mattter what you do. If there is a better way to do something, then by all means do it better. If it is no better, then stick to the Delphi way, to reduce the issues of porting.

Jeff.

Sure, that sounds fine, but why change it to be
different from Delphi? That makes it harder to
port applications. Is there a good reason for
it? It isn't that critical obviously and if
there is a good reason then that is fine.

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

+ From:
+
+ I have the same opinion. I think Lazarus is not just for
+ Windows anymore, so I'd leave the units as they are.

For porting issus it is easier if we follow the VCL. Why especially for buttons an own unit ? Makes no sense to me.

+ Curtis White wrote:
+
+ > I think in the past we decided that everything doesn't have to be exactly
+ > the same as Delphi, but if it isn't, then we need to document it so that we
+ > can make Lazarus do the conversions.

If we deviate from Delphi we sure need to document it.

+ > That is how TNotebook is. The TNotebook control in Delphi does not
+ > have tabs but the LCL one does. Also, we don't have a TTabbedNotebook
+ > any more as Delphi does.

As I understood in the past it was only a temporary solution the get things done. IMO it doesn't mean that it has to stay this way forever.

+ > So I don't see a problem with having buttons in a different unit. It is
+ > easier to determine where buttons are that way. The stdctrls name isn't
+ > really very helpful in determining what is in that unit. The reason Borland
+ > named it that is because those are standard Windows controls and a lot of
+ > developers prior to Delphi knew them that way. But since Lazarus isn't
+ > built just for Windows, some of those names don't make a lot of sense.
+ > Under Linux, the name stdctrls really doesn't mean anything useful, other

That also count for the other units. (can you tell what is in extctrls ? ;-)

Marc

We have a property called
SHOWTABS
that you can set to false and the tabs aren't visible then. Is that sufficient?

Shane

>> 05/05/00 08:08AM >>>

Just my 2c on this (below)... I really find the
notebook useful for things like wizards (eg.
InstallShield) where you don't actually want tabs. I do think it should be restored to the original
behaviour.

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Good points. I was envisaging a scenario where you work hand-in-hand with Delphi and Lazarus. In the C++ realm people sometimes use one C++ compiler for one bit of an application and another for a different part of the app. You can pick and choose. Of course, that doesn't usually extend to the GUI...

I agree that where improvements can be made they
should be made. Borland is obviously going to have to make changes to Delphi as we know it for Kylix and I'm sure the VCL will look quite different. We obviously can't foresee the changes they're going to make
either, so Delphi-compatibility is probably less
important when you get down the finer details anyway.

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

This is exactly what I had before. But instead of inheriting TTabbedNotebook from TNotebook, I had them both inherit from TCustomNotebook. All the functionality for a Notebook is in TCustomNotebook. The only difference between TNotebook and TTabbedNotebook was Tabs were enabled on TTabbedNotebook and disabled on TNotebook.

I still like the idea of having just one that we can turn the tabs on and off. That is less to maintain. And if we provide a way to map TTabbedNotebook to TNotebook, then we solve the problem and only have one control to maintain.

Curtis

Well, what we can do is create a TNotebook and a TTabbedNotebook or a TPageControl and just inherit TNotebook so it'll all be the same class just one has ShowTabs set to false and one set to true.

That ok?
Shane

>> 05/08/00 08:17AM >>>

Sure, that sounds fine, but why change it to be
different from Delphi? That makes it harder to
port applications. Is there a good reason for
it? It isn't that critical obviously and if
there is a good reason then that is fine.

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

I agree with this idea - one ancestor to maintain, two descendent classes. Makes it compatible with Delphi.

Kevin.

__________________________________________________ Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/