Re: [Lazarus] array[0..n] of class of TSomething

2011-07-12 Thread Flávio Etrusco
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 .. 1] of Tp2pMessageClass;
>>> const
>>>   MsgTypes: Tp2pMessageClassArray = (
>>>     ...
>>>   );
>>
>> Free Pascal supports "class of" in declarations while Delphi does not, but
>> it's a seldom used feature so the developers of the code tools might not
>> have noticed that problem at all :)
>
> IMO this "comfort" is a misfeature, that bloats the compiler and all other
> parsers. It has not been introduced in Delphi for good reason.
>
> DoDi
>

Err, why pollute the namespace with an identifier you'll only refer
once? It's hardly essential but surely not a "misfeature" either.

-Flávio

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


[Lazarus] Weird Edit events

2011-07-12 Thread Hans-Peter Diettrich
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 been loaded. In contrast it should raise an 
event when changed programmatically, at least on demand. Every event 
handler should have a chance to check for *unmodified* Text, when the 
event was not caused by user editing.


The documentation is a bit thin WRT the occurence of events. E.g. what's 
the *intended* difference between OnExit and OnEditingDone? Of course 
it's not easy to cover all user actions, which should signal the end of 
user editing, but we should find a *useful* solution for all typical use 
cases. Then the implementation should be updated to implement the 
(re)defined behaviour, even if it may break legacy code. When this is 
not acceptable, new events have to be implemented, what IMO is not 
desireable.


The basic events OnExit and OnChange IMO are well defined, no need to 
change anything here. More complicated are events like OnEditDone, which 
depend on many more parameters. Here I feel an urgent need to specify 
the conditions, which can (or should not) lead to such an event.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] array[0..n] of class of TSomething

2011-07-12 Thread Hans-Peter Diettrich

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 = (
 ...
   );


Free Pascal supports "class of" in declarations while Delphi does not, 
but it's a seldom used feature so the developers of the code tools might 
not have noticed that problem at all :)


IMO this "comfort" is a misfeature, that bloats the compiler and all 
other parsers. It has not been introduced in Delphi for good reason.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Can't find unit LResources used by Component1

2011-07-12 Thread Mattias Gaertner
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 in svn trunk.

 
> My lazarus
> Lazarus 0.9.31 r31679M FPC 2.4.4 i386-linux-gtk 2
> 
> Same error for  lazarus win XP !


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


[Lazarus] Can't find unit LResources used by Component1

2011-07-12 Thread John Landmesser

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 win XP !

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] array[0..n] of class of TSomething

2011-07-12 Thread Sven Barth

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 "class of" in declarations while Delphi does not, 
but it's a seldom used feature so the developers of the code tools might 
not have noticed that problem at all :)


@Bernd: Would you create a bug report, please?

Regards,
Sven


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] How to bring application to from (top)

2011-07-12 Thread Sven Barth

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 to test this on Windows Mobile also,...


Well... as you said it's for Windows Mobile (or WinCE to be precisely)
I've posted a solution for that. On desktop Windows I've never needed
that functionality yet, cause I personally dislike it when an
application jumps to front when I don't want it to. Thus I prefer the
blinking solution there.


Seems to work...

Thanks...


You're welcome :)

Regards,
Sven


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] array[0..n] of class of TSomething

2011-07-12 Thread leledumbo
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.n3.nabble.com/Lazarus-array-0-n-of-class-of-TSomething-tp3162813p3163033.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RE : RE : RE : RE : RE : RE :RE:RE:RE:RE:FPC_REQUIRES_PROPER_ALIGNMENTdefinedonSolariscausescrashinlazarus

2011-07-12 Thread Mark Morgan Lloyd

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 
emulated 
and by its associated firmware (PC BIOS, Sun OBP etc.).




OK Got it. VNC server comes with a pseudo graphics card driver. Its probably
slower than the build in VNC server since the first runs on the emulated
cpu.


I've tacked some scripts etc. onto the wiki page I mentioned earlier.

> http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators

They work well for me, except for an ARM guest.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


[Lazarus] array[0..n] of class of TSomething

2011-07-12 Thread Bernd
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 this is complete nonsense:

implementation

const
  MsgTypes : array[0..1] of class of Tp2pMessage = (
Tp2pMessageVersion,
Tp2pMessageGetdata
  );// this will be a lot more classes later



and later i have the following:

  procedure TPeer.ProcessMessage;
  var
Msg: Tp2pMessage;
TMsg   : class of Tp2pMessage;
...

  begin

...

for TMsg in MsgTypes do begin
  if Header.Command = TMsg.GetCommand then begin
Msg := TMsg.Create(Buffer, Header.Length);
Msg.Parse;
Msg.Process;
break;
  end;
end;

(GetCommand is a class function).

I cannot use this syntax at all because Lazarus is not happy with with
my array declaration and codetools will only give me the followin
error whenever I use autocompletion:

"test.pas(42,35) Error: procedure or function or constructor or
destructor expected, but of found"
and the cursor is pointing to the second "of" in my array declaration.

Now the question: Is this all complete nonsense what I am trying here
and I am using it wrong or am trying to over-engineer a simple thing?
I'm trying to avoid a spaghetti-like monster-if from hell and want
most of the things that the received messages would do actually let
the messages do it themselves.

is there any possible variation of this design pattern so that Lazarus
will not complain (I haven't actually tested whether the above even
works because some parts are still missing but at least it seems to
compile with FPC 2.5.1.

Bernd

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Frames etc. problems

2011-07-12 Thread Hans-Peter Diettrich

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. 
Perhaps it was me who caused the strange effects ;-)


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] TScrollBox.OnMouseUp does not fire correctly on Windows

2011-07-12 Thread Torsten Bonde Christiansen

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 13:32, Torsten Bonde Christiansen wrote:

Hi List.

As I'm not 100% sure how mouse events are handled in Lazarus, this 
may be a dumb question so please bear with me.


It seems as if a TScrollBox does not fire a OnMouseUp event (only in 
windows) when the mouse down was performed on the control,

but mouse up is done elsewhere (eg. outside the current window/form).

The same work fine for TPanel, TGroupBox, etc. Even using a 
TScrollBox in Linux and doing the same click work fine, so this

seems to be isolated to windows only.

I am using:
Lazarus 0.9.31 r31668 FPC 2.4.2 i386-win32-win32/win64

and
Lazarus 0.9.31 r31578M FPC 2.4.2 x86_64-linux-gtk 2


Is this a bug, which I guess it is since the TScrollBox work as I 
expect it to on Linux with GTK2?


Kind regards,
Torsten Bonde Christiansen.








--
Our Program who art in Memory, Hello be Thy Name.
Thy Operating System come, Thy Commands be done,
at the Printer as it is on the Screen.

Give us this day our daily Data, and forgive us our I/O Errors as we forgive 
those whose Logic Circuits are faulty. Lead us not into frustration, and 
deliver us from Power Surges,

for Thine is the Algorithm, the Application, and the Solution, looping forever 
and ever.

Return.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Frames etc. problems

2011-07-12 Thread Mattias Gaertner
 
 

 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 reports:
 >
 > Does there exist documentation about frame *development*? 
AFAIK: No.  
It was implemented with Delphi in mind. 
 
 

 >
 > When I have a form with embedded frames, and then modify an frame, what
 > changes are transparent to the forms where the frame is already used? 
Frames work very similar to inherited forms.
 
The IDE does not yet propagate changes in real time. You have to close a form
and reopen it to see changes to ancestors/frames. 
Of course it is planned to eventually propagate some changes in real time. See
below.  
 
That means: before you change a property of a frame, close all open forms using
that frame. 
 
The lfm files store only the differences. When loading a form the inherited
forms/frames lfm are applied one after the other. 
To create the diff TWriter needs the ancestor. That's why the IDE opens the
ancestors and keeps them open.
 
 

 >
 > E.g. adding methods should not be a problem, while changes to the GUI
 > may not be reflected properly (as expected) in the container forms? 
Most properties are no problem most of the time. And any property can be a
problem. 
 
 

 >
 > Should a form.lfm contain settings for *components* in the frame, after
 > such settings are changed in the frame itself? It looks to me as if the
 > form tries to retain the previous settings, and the designer inserts
 > according overrides in the form.lfm.
 >
 > Example:
 >
 > During development of the form's GUI I notice that a combobox contains
 > its name in the Text property. Since this is unwanted in general, I
 > modify the combobox.Text in the *frame*. Can I expect that this change
 > is reflected in the *form* immediately, or after closing and reopening
 > the form designer?
 >
 > Does it make a difference, whether the form is open in the designer, or
 > whether the form.lfm is open in the editor (view form as...), when
 > properties of an embedded frame are changed inside the frame?
 >
 >
 > It would help a lot when there existed documentation about what's going
 > on in the form and frame designers, so that a user can know what
 > (possibly unwanted) behaviour is by design, how to avoid it, and what
 > can be considered a bug. 
Here is a start:
http://wiki.lazarus.freepascal.org/IDE_Development#Frames
 
 
Mattias
 --
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Inserting many components on form

2011-07-12 Thread Max Vlasov
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 method (yes, can be more easy if the Add
> procedure of the TCollection as set as virtual, but...).

Fabio, as long as I remember, currently there's no typeinfo stored for
particualar collection item (you can look at any dfm or lfm containing
collections), so you will probably lose the type difference when you
collection is loaded. If it's hard to solve, I remember I experimented
with persistents (like TFont) being different types for the same owner
component type so you can use a property in the common collection item
that defines the type and this property recreate a persistent being
other property of the same item.

Max

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Frames etc. problems

2011-07-12 Thread Hans-Peter Diettrich

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, and then modify an frame, what 
changes are transparent to the forms where the frame is already used?


E.g. adding methods should not be a problem, while changes to the GUI 
may not be reflected properly (as expected) in the container forms?


Should a form.lfm contain settings for *components* in the frame, after 
such settings are changed in the frame itself? It looks to me as if the 
form tries to retain the previous settings, and the designer inserts 
according overrides in the form.lfm.


Example:

During development of the form's GUI I notice that a combobox contains 
its name in the Text property. Since this is unwanted in general, I 
modify the combobox.Text in the *frame*. Can I expect that this change 
is reflected in the *form* immediately, or after closing and reopening 
the form designer?


Does it make a difference, whether the form is open in the designer, or 
whether the form.lfm is open in the editor (view form as...), when 
properties of an embedded frame are changed inside the frame?



It would help a lot when there existed documentation about what's going 
on in the form and frame designers, so that a user can know what 
(possibly unwanted) behaviour is by design, how to avoid it, and what 
can be considered a bug.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Inserting many components on form

2011-07-12 Thread Fabio Luis Girardi
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 TCollection as set as virtual, but...). Finally, my
tags will be a descendant of TCollectionItem class. It isn't hard to
do, and keep the features of TCollection.

I'll start the implementation of this new idea, and post the result here.


Regards,

Fabio

2011/6/28 Hans-Peter Diettrich :
> fluisgira...@gmail.com schrieb:
>
>> Maybe I started my components with a wrong concept. Each component,
>> represents a memory (or a set of memories) on a remote device (like a PLC)
>> that can be read and/or written. These components can be linked with edits,
>> labels, progress bars and others controls created to show/modifies/stores
>> the value of these components.
>
> I'd "virtualize" the GUI, so that not every item is represented by a
> different component. It may help to store the items in a database, instead
> of using the component streaming mechanism and resource files.
>
> It's okay to use components (i.e. controls) for the GUI, but these should be
> limited to the required representation (dialogs...) of the data items. Then
> configure the visible controls to show the data for the currently selected
> item.
>
> DoDi
>
>

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus