I found another way to do this: extend the TCollection and write a new
procedure Add to allow choose what's the item class the user wants
create and make a Property editor for this new Collection class, that
will call this new Add method (yes, can be more easy if the Add
procedure of the TCollectio
Mattias Gaertner schrieb:
> 3) Sometimes it helps to remove the frames, and to add them again, but
> not always.
Helps for what?
A general question, Before I start submitting bug reports:
Does there exist documentation about frame *development*?
When I have a form with embedded frames
On Tue, Jul 12, 2011 at 2:53 PM, Fabio Luis Girardi
wrote:
> I found another way to do this: extend the TCollection and write a new
> procedure Add to allow choose what's the item class the user wants
> create and make a Property editor for this new Collection class, that
> will call this new Add
Hans-Peter Diettrich hat am 12. Juli 2011 um 14:13
geschrieben:
> Mattias Gaertner schrieb:
>
> > > 3) Sometimes it helps to remove the frames, and to add them again, but
> > > not always.
> >
> >
> >
> > Helps for what?
>
> A general question, Before I start submitting bug rep
To Lazarus developers.
Please note that I've updated this issue and create a patch and put it
on the bug tracker.
Kind regards,
Torsten Bonde Christiansen.
On 2011-07-11 14:45, Torsten Bonde Christiansen wrote:
Created bugreport:
http://bugs.freepascal.org/view.php?id=19712
On 2011-07-11
Mattias Gaertner schrieb:
That means: before you change a property of a frame, close all open
forms using that frame.
Very good idea :-)
Here is a start:
http://wiki.lazarus.freepascal.org/IDE_Development#Frames
Fine :-)
Now I'll resume my current work and keep all suggestions in mind.
Hi,
I have the following (I don't yet know whether this is only
pseudo-code to demonstrate what I mean (I have clearly done too much
Python during the last year) or whether something like this or similar
would actually work, I haven't tested it yet, although it compiles
without errors), or whether
Ludo Brands wrote:
That was a typo. I meant to say that a guest VNC (i.e. what
I'm using)
should allow you to specify the size and other parameters of
the screen
it is simulating, while the host VNC (i.e. provided by Qemu, which is
what you're using) is generally defined by the hardware being
Seems like codetools parser bug. Try writing it type by type:
type
Tp2pMessageClass = class of Tp2pMessage;
Tp2pMessageClassArray = array [0 .. 1] of Tp2pMessageClass;
const
MsgTypes: Tp2pMessageClassArray = (
...
);
--
View this message in context:
http://free-pascal-lazarus.989080
On 11.07.2011 05:14, Tommi Prami wrote:
On 8.7.2011 21:39, Sven Barth wrote:
On 08.07.2011 19:23, Tommi Prami wrote:
SetForegroundWindow(Screen.ActiveForm.Handle);
I think that at least in Windows XP the system will block the App from
coming into the Front.
Othervice it would work. Have t
On 12.07.2011 18:38, leledumbo wrote:
Seems like codetools parser bug. Try writing it type by type:
type
Tp2pMessageClass = class of Tp2pMessage;
Tp2pMessageClassArray = array [0 .. 1] of Tp2pMessageClass;
const
MsgTypes: Tp2pMessageClassArray = (
...
);
Free Pascal supports "
Hi,
try this:
New Package with new component derived from TComponent, select an *.png
as icon and compile
I get this error message:
component1.pas(8,22) Fatal: Can't find unit LResources used by Component1
My lazarus
Lazarus 0.9.31 r31679M FPC 2.4.4 i386-linux-gtk 2
Same error for lazarus
On Tue, 12 Jul 2011 22:20:24 +0200
John Landmesser wrote:
> Hi,
>
> try this:
>
> New Package with new component derived from TComponent, select an *.png
> as icon and compile
>
> I get this error message:
>
> component1.pas(8,22) Fatal: Can't find unit LResources used by Component1
Fixed i
Sven Barth schrieb:
On 12.07.2011 18:38, leledumbo wrote:
Seems like codetools parser bug. Try writing it type by type:
type
Tp2pMessageClass = class of Tp2pMessage;
Tp2pMessageClassArray = array [0 .. 1] of Tp2pMessageClass;
const
MsgTypes: Tp2pMessageClassArray = (
...
);
F
I came across some weird behaviour of TDirectoryEdit events, and traced
these down into the behaviour of the more basic components. IMO the
events, related to Edit fields, deserve reconsideration.
From the user VP, an Edit field should *not* trigger events while or
immediately after it has bee
On Tue, Jul 12, 2011 at 7:53 PM, Hans-Peter Diettrich
wrote:
> Sven Barth schrieb:
>>
>> On 12.07.2011 18:38, leledumbo wrote:
>>>
>>> Seems like codetools parser bug. Try writing it type by type:
>>>
>>> type
>>> Tp2pMessageClass = class of Tp2pMessage;
>>> Tp2pMessageClassArray = array [0 ..
16 matches
Mail list logo