Reimar Grabowski schrieb:
On Tue, 17 Apr 2012 19:46:08 +0200 Sven Barth
pascaldra...@googlemail.com wrote:
Well... class helpers are at least an officially supported hackish
approach unlike other forms of making a protected member visible.
Deriving my own class is certainly more work (as in
Mattias Gaertner schrieb:
On Tue, 17 Apr 2012 19:46:08 +0200
Sven Barth pascaldra...@googlemail.com wrote:
[...]
Well... class helpers are at least an officially supported hackish
approach unlike other forms of making a protected member visible.
I wonder what protected is still good for
Reimar Grabowski schrieb:
On Tue, 17 Apr 2012 22:19:45 +0200
Sven Barth pascaldra...@googlemail.com wrote:
type
TMyHackImage = class(TImage)
public
function DestRect: TRect;
end;
var
MyImage: TImage;
r: TRect;
begin
// let's suppose that MyImage contains a TImage
Am 17.04.2012 22:32, schrieb Reimar Grabowski:
On Tue, 17 Apr 2012 22:19:45 +0200
Sven Barthpascaldra...@googlemail.com wrote:
type
TMyHackImage = class(TImage)
public
function DestRect: TRect;
end;
var
MyImage: TImage;
r: TRect;
begin
// let's suppose that
Am 18.04.2012 07:31, schrieb patspiper:
On 18/04/12 01:11, Mattias Gaertner wrote:
On Wed, 18 Apr 2012 00:07:31 +0300
patspiperpatspi...@gmail.com wrote:
On 17/04/12 23:57, Mattias Gaertner wrote:
I save the project to project1.lpi and unit1.pas
I now run it again. It fails with
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Ishenin webpi...@mail.ru wrote:
21.11.11 21:38, Mattias Gaertner wrote:
At the same time when you compile from the console you can read the
error message.
Maybe the IDE stops reading the output on error and forgets to read the
rest.
Maybe
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Isheninwebpi...@mail.ru wrote:
21.11.11 21:38, Mattias Gaertner wrote:
At the same time when you compile from the console you can read the
error message.
Maybe the IDE stops reading the output on
Apologies for my lousy threading here, a message got chopped by our
firewall.
Is it possible to embed a standard dialogue in a custom form? For
example, if I wanted to filter text input through a user-specified
regular expression, can I set up a form containing a file-open
dialog plus
Il 18/04/2012 9.38, Sven Barth ha scritto:
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Isheninwebpi...@mail.ru wrote:
21.11.11 21:38, Mattias Gaertner wrote:
At the same time when you compile from the console you can read the
error message.
Maybe
Am 18.04.2012 10:14, schrieb Giulio Bernardi:
Il 18/04/2012 9.38, Sven Barth ha scritto:
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Isheninwebpi...@mail.ru wrote:
21.11.11 21:38, Mattias Gaertner wrote:
At the same time when you compile from the
Le 18/04/2012 09:42, Mark Morgan Lloyd a écrit :
Apologies for my lousy threading here, a message got chopped by our
firewall.
Is it possible to embed a standard dialogue in a custom form? For
example, if I wanted to filter text input through a user-specified
regular expression, can I
Il 18/04/2012 10.26, Sven Barth ha scritto:
Am 18.04.2012 10:14, schrieb Giulio Bernardi:
Il 18/04/2012 9.38, Sven Barth ha scritto:
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Isheninwebpi...@mail.ru wrote:
21.11.11 21:38, Mattias Gaertner wrote:
Sorry, on cell, so formatting limited here too.
Sample login form for mssql and sybase, i.e. 2 dbs at
bug 21619... committed as sample program in trunk.
I think the sample form could easily extended to support more dbs... Actually
want to do that some day and get it into lazarus...
Ludo brands
Am 18.04.2012 11:17, schrieb Giulio Bernardi:
Il 18/04/2012 10.26, Sven Barth ha scritto:
Am 18.04.2012 10:14, schrieb Giulio Bernardi:
Il 18/04/2012 9.38, Sven Barth ha scritto:
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011 06:20:39 +0800
Paul Isheninwebpi...@mail.ru
Il 18/04/2012 11.26, Sven Barth ha scritto:
Am 18.04.2012 11:17, schrieb Giulio Bernardi:
Il 18/04/2012 10.26, Sven Barth ha scritto:
Am 18.04.2012 10:14, schrieb Giulio Bernardi:
Il 18/04/2012 9.38, Sven Barth ha scritto:
Am 18.04.2012 09:32, schrieb Mattias Gaertner:
On Tue, 22 Nov 2011
I've been away from trunk for a few weeks due to problems. I notice that
the old LCL Widget Type on the Compiler Options - Paths page has been
replaced by a build mode entry which sets a macro, but the dropdown for
this doesn't have a default entry to match the current IDE.
Has default been
Antonio Fortuny wrote:
Le 18/04/2012 09:42, Mark Morgan Lloyd a écrit :
Apologies for my lousy threading here, a message got chopped by our
firewall.
Is it possible to embed a standard dialogue in a custom form? For
example, if I wanted to filter text input through a user-specified
reinierolislag...@gmail.com wrote:
Sorry, on cell, so formatting limited here too.
Sample login form for mssql and sybase, i.e. 2 dbs at
bug 21619... committed as sample program in trunk.
I think the sample form could easily extended to support more dbs... Actually
want to do that some day and
OK, If I can lead on from this. The cause of bug 21792 that I raised
yesterday is, I'm told, that I'd set the main form visible but
minimised. The reason I'd done this is that before the form was
displayed I wanted the user to provide database login credentials, I
couldn't rely on a
Giulio Bernardi ugi...@gmail.com hat am 18. April 2012 um 11:17 geschrieben:
[...]
Ops, you're right. I checked now and it is '-vd' (verbose with debug output)
that passes -v to fpcres.
Thanks for the hint.
I added a quickfix item to add that hint to the message and changed the filter
to
Ludo Brands wrote:
OK, If I can lead on from this. The cause of bug 21792 that I raised
yesterday is, I'm told, that I'd set the main form visible but
minimised. The reason I'd done this is that before the form was
displayed I wanted the user to provide database login credentials, I
couldn't
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk hat am 18. April 2012 um
11:38 geschrieben:
I've been away from trunk for a few weeks due to problems. I notice that
the old LCL Widget Type on the Compiler Options - Paths page has been
replaced by a build mode entry which sets a macro, but
Hi,
I'm playing around with a non-lcl-designer to design xib forms. This
works quite nice, but there are a lot of issues.
Basic problem is that the 'objects' which are placed on the designer are
not TComponent descendants. In fact they aren't even classes but
objcclasses.
To circumvent this
Just my 2 c:
I feel it was a really great idea to allow for multiple build mode
variables. fpGUI makes good use of that by allowing for defining the
backend behind the fpGUI layer. (Hopefully CustomDrawn once will do the
same.)
Moreover I can think of a lot more advantageous uses of
Joost van der Sluis jo...@cnoc.nl hat am 18. April 2012 um 13:45 geschrieben:
Hi,
I'm playing around with a non-lcl-designer to design xib forms. This
works quite nice, but there are a lot of issues.
Basic problem is that the 'objects' which are placed on the designer are
not TComponent
On Wed, 2012-04-18 at 14:16 +0200, Mattias Gaertner wrote:
Joost van der Sluis jo...@cnoc.nl hat am 18. April 2012 um 13:45
geschrieben:
To circumvent this problem I created a unit with TComponent
descendants
with the same name as the objcclasses I really want to use. I
thought
that
patspiper schrieb:
No, FormClose() isn't called when modal form is hidden via Hide();
Correct
, so form still exists and it can be called with ShowModal() or Show()
again.
I beg to differ here as Showmodal should not exit unless the modal form
is closed.
A modal form (dialog) can be
Michael Schnell wrote:
Just my 2 c:
I feel it was a really great idea to allow for multiple build mode
variables. fpGUI makes good use of that by allowing for defining the
backend behind the fpGUI layer. (Hopefully CustomDrawn once will do the
same.)
Moreover I can think of a lot more
On 18/04/2012 11:53, Hans-Peter Diettrich wrote:
patspiper schrieb:
No, FormClose() isn't called when modal form is hidden via Hide();
Correct
, so form still exists and it can be called with ShowModal() or
Show() again.
I beg to differ here as Showmodal should not exit unless the modal
On Wednesday 18 of April 2012 15:22:27 Martin wrote:
On 18/04/2012 11:53, Hans-Peter Diettrich wrote:
patspiper schrieb:
No, FormClose() isn't called when modal form is hidden via Hide();
Correct
, so form still exists and it can be called with ShowModal() or
Show() again.
I
On 18/04/2012 15:27, zeljko wrote:
In LCL there is
Screen.DisableForms()
+1 , that's why I implemented hiding of modal form as it is - it
simply works on all platforms, and Delphi behaviour looks pretty
unlogical to me (but even that can work - see my today patches
attached at issue).
2012/4/17 zeljko zel...@holobit.net
**
On Tuesday 17 of April 2012 17:41:54 patspiper wrote:
This is related to bug #15390:
My understanding is that Showmodal blocks until the form is closed.
Hiding the form should have no effect.
try
Self.Hide;
Form2.ShowModal; //-
On 18/04/12 16:22, Martin wrote:
On 18/04/2012 11:53, Hans-Peter Diettrich wrote:
patspiper schrieb:
No, FormClose() isn't called when modal form is hidden via Hide();
Correct
, so form still exists and it can be called with ShowModal() or
Show() again.
I beg to differ here as
On 18/04/12 17:27, zeljko wrote:
On Wednesday 18 of April 2012 15:22:27 Martin wrote:
On 18/04/2012 11:53, Hans-Peter Diettrich wrote:
patspiper schrieb:
No, FormClose() isn't called when modal form is hidden via Hide();
Correct
, so form still exists and it can be called
On 18/04/12 17:39, Martin wrote:
On 18/04/2012 15:27, zeljko wrote:
In LCL there is
Screen.DisableForms()
+1 , that's why I implemented hiding of modal
form as it is - it simply works on all platforms, and Delphi
behaviour looks pretty unlogical to me (but even that can work -
see my
On 18/04/2012 17:53, patspiper wrote:
On 18/04/12 17:39, Martin wrote:
But this is not a bug.
And Delphi docs, IMHO are not making a 100% clear statement about this.
It is a bug considering that both Delphi and Lazarus docs are clear
about it: ShowModal does not return until the form is
On Tue, 17 Apr 2012 11:40:00 +0200
zeljko zel...@holobit.net wrote:
[...]
There's no env variables which points to this, also there's nothing
in wm atoms what says that liboverlay is used.
What is the next step after finding out that liboverlay is active?
...at least
On Tue, 17 Apr 2012 17:06:47 +0200
Marc Weustink marc.weust...@cuperus.nl wrote:
Mattias Gaertner wrote:
On Tue, 17 Apr 2012 12:12:21 +0200
Marc Weustinkmarc.weust...@cuperus.nl wrote:
Mattias Gaertner wrote:
Reimar Grabowskireimg...@web.de hat am 16. April 2012 um 16:42
Op 18 april 2012 19:48 heeft Mattias Gaertner
nc-gaert...@netcologne.de het volgende geschreven:
I implemented a test to find out if liboverlay is active for a
scrolledwindow scrollbar and write a warning.
And if it is active I used signal 'value-changed' instead of
'change-value'. Now
On 18/04/12 20:09, Martin wrote:
On 18/04/2012 17:53, patspiper wrote:
On 18/04/12 17:39, Martin wrote:
But this is not a bug.
And Delphi docs, IMHO are not making a 100% clear statement about this.
It is a bug considering that both Delphi and Lazarus docs are clear
about it: ShowModal does
On Wednesday 18 of April 2012 16:39:59 Martin wrote:
On 18/04/2012 15:27, zeljko wrote:
In LCL there is
Screen.DisableForms()
+1 , that's why I implemented hiding of modal form as it is - it
simply works on all platforms, and Delphi behaviour looks pretty
unlogical to me (but
On Wednesday 18 of April 2012 16:47:43 William Oliveira Ferreira wrote:
2012/4/17 zeljko zel...@holobit.net
**
On Tuesday 17 of April 2012 17:41:54 patspiper wrote:
This is related to bug #15390:
My understanding is that Showmodal blocks until the form is closed.
On Wednesday 18 of April 2012 19:48:12 Mattias Gaertner wrote:
On Tue, 17 Apr 2012 11:40:00 +0200
zeljko zel...@holobit.net wrote:
[...]
There's no env variables which points to this, also there's
nothing in wm atoms what says that liboverlay is used.
What is the next
On Wednesday 18 of April 2012 20:05:35 patspiper wrote:
On 18/04/12 20:09, Martin wrote:
On 18/04/2012 17:53, patspiper wrote:
On 18/04/12 17:39, Martin wrote:
But this is not a bug.
And Delphi docs, IMHO are not making a 100% clear statement about this.
It is a bug considering that
On Wednesday 18 of April 2012 19:48:12 Mattias Gaertner wrote:
On Tue, 17 Apr 2012 11:40:00 +0200
zeljko zel...@holobit.net wrote:
[...]
There's no env variables which points to this, also there's
nothing in wm atoms what says that liboverlay is used.
What is the next
On Wed, 2012-04-18 at 14:42 +0200, Joost van der Sluis wrote:
On Wed, 2012-04-18 at 14:16 +0200, Mattias Gaertner wrote:
Joost van der Sluis jo...@cnoc.nl hat am 18. April 2012 um 13:45
geschrieben:
I will create a test example so we can check what is possible and what
is needed.
On 18/04/2012 19:05, patspiper wrote:
Furthermore, Hide() does not trigger the OnCloseQuery and OnClose events.
Yes. But that are side effects.
The actual action on the widget / handle (the window as known by the
win-api or gtk) are the same: The form (window widget) is taken of the
screen
On 18/04/2012 19:26, zeljko wrote:
On Wednesday 18 of April 2012 20:05:35 patspiper wrote:
On 18/04/12 20:09, Martin wrote:
On 18/04/2012 17:53, patspiper wrote:
On 18/04/12 17:39, Martin wrote:
But this is not a bug.
And Delphi docs, IMHO are not making a 100% clear statement
On 18/04/12 21:26, zeljko wrote:
Maybe I will implement it to be delphi compat but first must test it
on all platforms. Also I would like to have property inside
TCustomForm which can
change behaviour of ShowModal() when Hide() is called.
1.I like current implementation because you can
On 18/04/12 21:56, Martin wrote:
On 18/04/2012 19:05, patspiper wrote:
Furthermore, Hide() does not trigger the OnCloseQuery and OnClose events.
Yes. But that are side effects.
The actual action on the widget / handle (the window as known by the
win-api or gtk) are the same: The form
On 18/04/12 22:01, Martin wrote:
On 18/04/2012 19:26, zeljko wrote:
On Wednesday 18 of April 2012 20:05:35
patspiper wrote:
On 18/04/12 20:09, Martin wrote:
On 18/04/2012 17:53, patspiper
wrote:
On 18/04/12 17:39, Martin
wrote:
But this is not a bug.
And Delphi docs, IMHO are
not
Hi,
(While I'm re-writing my package, I can better report some problems I'm
having immediately)
I want to set TBaseCompilerOptions.ExecuteAfter in a package, but to do
that the package has to depend on the ide package. Not ideal, if not
impossible.
Could .ExecuteAfter (and probably before) be
On Wed, 18 Apr 2012 20:21:30 +0200
zeljko zel...@holobit.net wrote:
On Wednesday 18 of April 2012 19:48:12 Mattias Gaertner wrote:
On Tue, 17 Apr 2012 11:40:00 +0200
zeljko zel...@holobit.net wrote:
[...]
There's no env variables which points to this, also there's
On Wed, 18 Apr 2012 09:58:56 +0200
Hans-Peter Diettrich drdiettri...@aol.com wrote:
But often (depending on the compiler) the mere declaration
of an empty derived class allows to access protected members of the base
class.
What does depending on the compiler mean? The compiler is obviously
On Wed, 18 Apr 2012 09:50:16 +0200
Hans-Peter Diettrich drdiettri...@aol.com wrote:
It should be mentioned that class helpers do not solve all problems,
Not being able to access a member that you should not access is not a problem.
It's what visibility in OOP is ment to do. It is by design
But often (depending on the compiler) the mere declaration
of an empty derived class allows to access protected members of the base
class.
What does depending on the compiler mean? The compiler is obviously FPC.
If it is really true that you can access protected members in that way (like
Svens
On Wed, 18 Apr 2012 19:52:46 +0200
Mattias Gaertner nc-gaert...@netcologne.de wrote:
I don't see many worms in the can, so I made it public.
It's a useful feature that costs us not much.
Thanks, much better than this class helper stuff.
R.
--
___
It should be mentioned that class helpers do not solve all problems,
Not being able to access a member that you should not access is not a problem.
It's what visibility in OOP is ment to do. It is by design that you cannot
access that member. Having an official way to do this is IMHO bad.
On Wednesday 18 of April 2012 21:01:39 Martin wrote:
On 18/04/2012 19:26, zeljko wrote:
On Wednesday 18 of April 2012 20:05:35 patspiper wrote:
On 18/04/12 20:09, Martin wrote:
On 18/04/2012 17:53, patspiper wrote:
On 18/04/12 17:39, Martin wrote:
But this is not a bug.
On Wednesday 18 of April 2012 21:54:05 Mattias Gaertner wrote:
On Wed, 18 Apr 2012 20:21:30 +0200
zeljko zel...@holobit.net wrote:
On Wednesday 18 of April 2012 19:48:12 Mattias Gaertner wrote:
On Tue, 17 Apr 2012 11:40:00 +0200
zeljko zel...@holobit.net wrote:
[...]
60 matches
Mail list logo
