Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-05

TPairSplitter vs. TSplitter

7 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Santhoff

Hi,

I started designing a form using a TPairSplitter. When searching for docs I found an article saying TPairSplitter is an older, non-Delphi compatible implementation.

Since I do not care for Delphi and had started already I decided to go on and see. Now I saw: using the gtk2 widget set for lazarus and the application there are no selection marks when hitting any of the components inside the splitter sides with the mouse. Those components are seltected as can be seen in the object inspector.

Is TPairSplitter buggy? Or gtk2?

Summing up I want to know:

Is it a good idea to go on using TPairSplitter or if I should better switch to TSplitter?

TIA,

Marc Santhoff

Reply by email

Paul Ishenin
to Marc Santhoff
Marc Santhoff wrote
Is TPairSplitter buggy? Or gtk2?

Gtk2. It happens with other controls too.

Summing up I want to know: Is it a good idea to go on using TPairSplitter or if I should better switch to TSplitter?

Previosly we thought to remove TPairSplitter. TPairSplitter uses 2 panels + splitter on other than gtk/gtk2 platforms. Therefore it adds 2 unneeded window handles. This makes your form more heavy - it needs more os resources, positioning and resizing requires more operations.

I would use TSplitter only.

Best regards,
Paul Ishenin.

Reply by email

Marc Santhoff
to Paul Ishenin
Paul Ishenin wrote 14 lines
Marc Santhoff wrote: > Is TPairSplitter buggy? Or gtk2? Gtk2. It happens with other controls too. > Summing up I want to know: > > Is it a good idea to go on using TPairSplitter or if I should better > switch to TSplitter? Previosly we thought to remove TPairSplitter. TPairSplitter uses 2 panels + splitter on other than gtk/gtk2 platforms. Therefore it adds 2 unneeded window handles. This makes your form more heavy - it needs more os resources, positioning and resizing requires more operations.

I'd vote for removing, if in the end it happens to be a bad decision to use it because it is not fully funtional (combined with gtk2) and with TSplitter there is an alternative.

I would use TSplitter only.

Will do so, too.

Many thanks for clearing things up.

Marc Santhoff

Reply by email

Vincent Snijders
to Marc Santhoff
Marc Santhoff wrote 17 lines
Am Montag, den 01.06.2009, 08:58 +0800 schrieb Paul Ishenin: > Marc Santhoff wrote: >> Is TPairSplitter buggy? Or gtk2? > Gtk2. It happens with other controls too. > >> Summing up I want to know: >> >> Is it a good idea to go on using TPairSplitter or if I should better >> switch to TSplitter? > Previosly we thought to remove TPairSplitter. TPairSplitter uses 2 > panels + splitter on other than gtk/gtk2 platforms. Therefore it adds 2 > unneeded window handles. This makes your form more heavy - it needs more > os resources, positioning and resizing requires more operations. I'd vote for removing, if in the end it happens to be a bad decision to use it because it is not fully funtional (combined with gtk2) and with TSplitter there is an alternative.

Can we refer to you to port all existing code?

I don't mind deprecating it.

Vincent

Reply by email

Graeme Geldenhuys
to Vincent Snijders

2009/6/1 Vincent Snijders :

I don't mind deprecating it.

Then I would suggest moving it into a "Deprecated" tab in the components palette as well. As far as I know you can mark a method deprecated in the Object Pascal language, but I don't know of a whole class. I also don't believe Lazarus can visually (on the component palette) show that a component is deprecated. So a dedicated "Deprecated" tab seems the only logical choice.

PS:
Is there a way to mark a whole class as deprecated in Object Pascal / Delphi?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Marc Weustink
to Marc Santhoff: I'd vote for removing, if in the end it happens to be a bad decision to use it because it…
Marc Santhoff wrote 17 lines
Am Montag, den 01.06.2009, 08:58 +0800 schrieb Paul Ishenin: > Marc Santhoff wrote: >> Is TPairSplitter buggy? Or gtk2? > Gtk2. It happens with other controls too. > >> Summing up I want to know: >> >> Is it a good idea to go on using TPairSplitter or if I should better >> switch to TSplitter? > Previosly we thought to remove TPairSplitter. TPairSplitter uses 2 > panels + splitter on other than gtk/gtk2 platforms. Therefore it adds 2 > unneeded window handles. This makes your form more heavy - it needs more > os resources, positioning and resizing requires more operations. I'd vote for removing, if in the end it happens to be a bad decision to use it because it is not fully funtional (combined with gtk2) and with TSplitter there is an alternative.

At the time we implemented TSplitter, I voted to keep the TPairSplitter. If I look at my uses of a TSplitter in most cases I need something as a TPairSplitter. Which means that I need to use 2 TPanels myself. I think there are more users needing this.
IMO, a widgetset can do this more efficient with some native control (1 handle), than using 2 panels (3 handles). So I still think it has its need, and imo it doesn't have to get deprecated

Marc

Reply by email

Marc Santhoff
to Marc Weustink
Marc Weustink wrote 23 lines
Marc Santhoff wrote: > Am Montag, den 01.06.2009, 08:58 +0800 schrieb Paul Ishenin: >> Marc Santhoff wrote: >>> Is TPairSplitter buggy? Or gtk2? >> Gtk2. It happens with other controls too. >> >>> Summing up I want to know: >>> >>> Is it a good idea to go on using TPairSplitter or if I should better >>> switch to TSplitter? >> Previosly we thought to remove TPairSplitter. TPairSplitter uses 2 >> panels + splitter on other than gtk/gtk2 platforms. Therefore it adds 2 >> unneeded window handles. This makes your form more heavy - it needs more >> os resources, positioning and resizing requires more operations. > > I'd vote for removing, if in the end it happens to be a bad decision to > use it because it is not fully funtional (combined with gtk2) and with > TSplitter there is an alternative. At the time we implemented TSplitter, I voted to keep the TPairSplitter. If I look at my uses of a TSplitter in most cases I need something as a TPairSplitter. Which means that I need to use 2 TPanels myself. I think there are more users needing this.

I'll have to learn more about the usage of TSplitter to finally decide. But the use of two panels was the reason why I selected TPairSplitter - without knowing exactly if TSplitter can do the same. I'll see when I re-design the form in question.

But the missing *visual selection handles* (those little black squares showing up in design mode, *not* system ressources) are a constant source of mistakes while designing the form.

IMO, a widgetset can do this more efficient with some native control (1 handle), than using 2 panels (3 handles). So I still think it has its need, and imo it doesn't have to get deprecated

The system ressources are no problem at all, me thinks. If an application has one thousand forms they will surely not be created all at once. I never heard of any exceptions or errors because of missing handles since abandoning Windows 95/98.

Marc Santhoff

Reply by email