Re: [Lazarus] array[0..n] of class of TSomething
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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