Re: [Lazarus] ARM-WinCE does not complie from the IDE (+ a few question)
1. Am I supposed to build the ARM-WinCE units from the IDE? (This did not work before) This always worked. 2. If yes, I guess not everything needs to compiled or WinCE. Which options should be included? It's documented in the wiki: http://wiki.lazarus.freepascal.org/Windows_CE_Interface#Using_the_snapshot_add-on_installer If you want to rebuild LCL yourself then you need to add the operating system wince and architecture arm in the Build Lazarus dialog. You need to use the advanced tab for that. 3. Currently I am using FPC 2.2.2. Is this the currently recommended FPC version for WinCE. If not, I would a appreciate a link to the proper SVN FPC repository. Yes, 2.2.2 is the recommend version. 4. Are the suggestions for preparing Lazarus for WinCE manually still valid on the Lazarus website? I remember there was some confusion between two senior developers of Lazarus (or maybe FPC ) about where the compiled units should be placed. Has this been settled by now? That was only for manually setting up the interface. Use should use the add-on installer, unless there is a very good reasion to avoid it. -- Felipe Monteiro de Carvalho ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
Felipe Monteiro de Carvalho schrieb: My suggestion would be to create a layout class yourself. It should be easy. What's the base class for an layout manager? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
On Sun, Jan 11, 2009 at 9:57 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: What's the base class for an layout manager? There is none specific. I would suggest trying TCustomControl if you also want to draw borders or TControl if you just want to position childs. -- Felipe Monteiro de Carvalho ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
On 1/10/09, Lord Satan reimg...@web.de wrote: Did you ever do a 'more complex' GUI with Qt? I am working with Qt in my job and I would gladly trade Qt's layouts for Lazarus' anchoring and friends? It takes ages to align Qt's layouts and spacers in a way that they work at least a little bit like you wish. The Qt-Designer is more hindering than helping and very often I have more space between my GUI elements than I want to have. Perhaps me and my colleagues are just too stupid to use Qt, but our GUI design is most of the time 'just good enough' and not like we imagined to do it. Sorry for ranting, but I can't let a chance to bash Qt's layouts just pass. ;-) MiG Layout is simply fantastic. Try the demo on there website and see for yourself! You only need one layout manager to build any GUI. They once had a test like that - duplicate any application's GUI using MiG Layout. There wasn't a single GUI they couldn't reproduce with little effort. You can even specify spacing between components in mm, inches, cm, pixels etc... It's resolution independent and dpi independent. The other neat feature is the Debug mode, where it highlights containing components etc.. to help you design your GUI layout. The layout interface is relatively simple, so no GUI designer is required - it's all possible from a few lines of code. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
On Sun, 2009-01-11 at 03:52 +0100, Lord Satan wrote: On Sat, 10 Jan 2009 21:37:28 + David W Noon david.w.n...@ntlworld.com wrote: What you are ultimately saying is that Lazarus's form designer is easier to use than Qt designer. No, I am not. I am saying that with the Qt layouts we don't achieve the look we want and that the Qt-Designer (as a bonus) is a major PITA, too. Doing it by hand does not fix the shortcomings of layouts and spacers and just adds ugly code. I am not talking about one form with some memos, buttons, etc here and there. We have a highly dynamical GUI in our application, with lots of plugins adding/removing their own GUI-elements at runtime or extending existing GUI-elements. We switched from hand coded GUI to ui-files as the old system just became unmanageable. Once again, this is not about Qt-Designer vs Lazarus' form designer. Layouts are a nice and easy way for simple GUIs, but too restricted for more complex tasks. I would post screen shots of the problems, but I am unfortunately not allowed to do this. But you did not answer my question. Do you have experience with developing complex layouts in Qt or are you just talking about simple stuff? By my standards they were reasonably complex. However, all the dialogues are statically populated with controls, so the layouts are for resizing and/or repositioning controls whose initial positions are known at compile time -- i.e. no dynamic plugins. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Dispatching GUI messages from background threads
On Sun, 2009-01-11 at 09:59 +0700, Paul Ishenin wrote: David W Noon wrote: The only function like that I could find was SimpleSendMessage(), which produced the same result as Dispatch() and DeliverMessage(), but without supplying any message data. In which unit is SendMessage() defined? add LCLIntf unit to your uses section and you'll get SendMessage and PostMessage. Both methods of message transfer! Many thanks. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
Graeme Geldenhuys schrieb: You can even specify spacing between components in mm, inches, cm, pixels etc... It's resolution independent and dpi independent. What kind of graphics are supported? Pixel-based bitmaps do not fit well together with otherwise measured fonts and other GUI elements. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
Felipe Monteiro de Carvalho schrieb: What's the base class for an layout manager? There is none specific. I would suggest trying TCustomControl if you also want to draw borders or TControl if you just want to position childs. That doesn't answer the question, how to marry controls and layout manager. How will the form designer interact with the layout manager... DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OSX: Handles and WindowRefs
Duncan Parsons wrote: Hi, I seem to have run into a problem with what is essentially nomenclature.. Since LCL has used Delphi as its template, there's a lot of Windows based conventions, but that doesn't totally map to other systems. Indeed, that is why a Reference property as Handle replacement is introduced. For instance, TForm.Handle in windows repesents the tag that the OS gives to the rectangle I see on screen. I would have thought that each underlying widgetset interface would then use this to maintain some consistency at a higher level, eg on OSX, this would be filled with the WindowRef that OSX uses. However, I cannot see this happening (unless I'm looking in the wrong place). TCarbonWindow has a fWindowRef field and property that references it, but this is at widgetset level, and so not visible to TForm. Each Widgetset is free to return whatever it likes ad Handle to their underlying data structures. As you can see in other replies, for carbon it was AWindow := WindowRef(TCarbonWidget(Form1.Handle).Widget); and now AWindow := TCarbonWindow(Form1.Handle).Window; The idea behind TWInControl.Reference is to abstract this and to allow direct widgetaccess the same time. In the future retrieving the window would become something like: AWindow := WinControl.Reference as ICarbonHiView).Window; or similar for gtk AWindow := WinControl.Reference as IGdkWindow).Window; etc.. Ofcoarse this is all future and depends a bit on when I feel like doing such big change. I see the HandleAllocated and GetReferenceAllocated code lying around, THats indeed the start. but they don't seem to tell me what I'm after. What I'd like to know is if I have a function in OSX that is asking for a form's WindowRef, do I pass it self.Handle, or is there something else I should be using. At the moment it is not working as I would hope. For instance calling GetWindowAttributes(WindowRef(self.Handle),myAttributes) gives me an exception each time. Any ideas on what I should be looking for? See other replies. Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
On Sun, 11 Jan 2009 16:49:10 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Felipe Monteiro de Carvalho schrieb: What's the base class for an layout manager? There is none specific. I would suggest trying TCustomControl if you also want to draw borders or TControl if you just want to position childs. That doesn't answer the question, how to marry controls and layout manager. How will the form designer interact with the layout manager... At the moment this is completely in the LCL. Controls can override various methods to alter that behavior and applications can set events. For example you can create a component that sets all OnResize/OnChangeBounds events. There is no global or form based possibility to override. You are welcome to make a proposal. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Saving user created component structure to LFM file
Hi, I have a problem saving a certain component struicture to an LFM (lazarus) file and read it back. since a good amount of code is in FPC, I am not sure which list to go to? There is classes/writer.inc with has TBinaryObjectWriter. This is where things go first. Then, later this gets translated into text. This translation seems to be stricter in terms of what can be nested. Anyway the problem is, that if I want to save a component (that can be of different class/classes) then I can use WriteComponent. But only if I am in a Component that is itself written with WriteComponent. In the final LFM it seems a Component can only be nested in an other component. It does not seem to be possible to put it in: - Not in a subcomponent (because a subcomponent does not write it's class, but just the properties that are visible for the class given by the property property Foo: TPanel read .. write ... writes Foo.Name = 'abc' Foo.Top = 1 ... - Not in a TCollection, or at least I havent managed. Also again a TCollection is restricted to one classs for all Items - Not Using DefineProperties All propwerties with define property are of the kind Name = Value I can add a list, but even inside the list I can not write a component What I want to archive is theFollowing. I have TMainComponent = class (foo) property Options : TPersitentBar read x write x; end If It has to be it can be a TComponent, with SubComponent in TComponentStyle. Problem 1) Options is always created in the constructor, it can not be stored as a nested Component in the LFM. If it was, it would exist twice (once created in the constructor, and once loaded from the lfm) TPersitentBar should have a list of components, variable number, and different subclasses (could inherit from TPersistent, only Component if it makes it easier) How can I get this list saved into the lfm? Each item has a diff class, and diff properties, so they must saved via WriteComponent. (Which does not work for DefineProerties) And of course a default list of items is created in the constructor, so I need to detect if they are loaded, and remove the defaults. Any Idea? Example of the final structure (if only it was valid) object MainComp1 : TMainComponent Options.AllowFoo = 1 Options.AllowABC = 2 object Options.SubOptionsForCars : TCarOptions MAxCar = 4 end object Options.SubOptionsForTrains : TTrainOptions MAxTrain = 1 end end Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OSX: Handles and WindowRefs
Marc Weustink schrieb: Each Widgetset is free to return whatever it likes ad Handle to their underlying data structures. As you can see in other replies, for carbon it was AWindow := WindowRef(TCarbonWidget(Form1.Handle).Widget); and now AWindow := TCarbonWindow(Form1.Handle).Window; The idea behind TWInControl.Reference is to abstract this and to allow direct widgetaccess the same time. In the future retrieving the window would become something like: AWindow := WinControl.Reference as ICarbonHiView).Window; or similar for gtk AWindow := WinControl.Reference as IGdkWindow).Window; The (Windows) Handle already *is* an abstraction. Why not use it for every widgetset? It may depend on the widgetset, what can be done with a Handle. This is where general methods (for every widgetset) and specific methods should be separated. We might sort out true Windows specific methods, and implement the remaining set of procedures/functions for every widgetset. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
Mattias Gaertner schrieb: That doesn't answer the question, how to marry controls and layout manager. How will the form designer interact with the layout manager... At the moment this is completely in the LCL. Controls can override various methods to alter that behavior and applications can set events. For example you can create a component that sets all OnResize/OnChangeBounds events. There is no global or form based possibility to override. You are welcome to make a proposal. Bite ;-) Since docking managers are kind of layout managers, I'd suggest an extension of the IDockManager interface. Unfortunately I'm still recovering from catching a cold (Grippe), but I hope to contribute soon :-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
