[Lazarus] Mantis #18448. Changes to win32object.inc, +procedure TWin32WidgetSet.AppInit(var ScreenInfo: TScreenInfo);
Hi Lazarus list, I am proposing some changes to +procedure TWin32WidgetSet.AppInit(var ScreenInfo: TScreenInfo); in win32object.inc. These are changes to enable exception error handling which *should* be reported in file 'AppInit_backtrace.txt'. This was suggested as a general hint by someone else on this list. Refer to win32object.inc.diff (attached to #18448) This issue is now reported as: http://mantis.freepascal.org/view.php?id=18448 pew Hi Mattias, see below changes to writeln statement. From: pewilliams2010 at live.com To: lazarus at lists.lazarus.freepascal.org Date: Sun, 26 Dec 2010 14:07:45 +1100 Subject: [Lazarus] (no subject) Dear Mattias, Here are my attempts to find your memory leak. So far it does not compile. Too many parameters. See attached file. /lazarus/lcl/interfaces/win32/win32object.inc PEW -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
2011/1/9 Zaher Dirkey parm...@gmail.com: If you not use it, would you please make it as an option (new Platform). Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
On 8 January 2011 17:16, Hans-Peter Diettrich drdiettri...@aol.com wrote: What's the purpose of setting the mouse capture in the LCL? While nobody seems to know, I found that TSpltter uses mouse capture. MouseCapture (at least under fpGUI) is also used while the mouse button is down, eg on a TButton. For example (i think this works under LCL too). Click a TButton, and hold the mouse button down. Now move the mouse cursor outside the TButton bounds. The TButton should pop up (normal state again), and when you hove the mouse over the TButton, the mouse would be pressed again. Mouse events normally get delivered only to the window underneath the mouse. MouseCapture, captures the mouse input and makes sure it gets delivered to a specific window even if the mouse is over another window. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote: 2011/1/9 Zaher Dirkey parm...@gmail.com: If you not use it, would you please make it as an option (new Platform). Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. I think it makes more sense to skip SDL and directly use the linux framebuffer. Eliminate a layer. You already have direct support for all other 'platforms' that SDL supports, so why add another (changing) dependency/point of failure? It may be initially harder, but will prove easier to maintain in the long run. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mantis #18448. Changes to win32object.inc, +procedure TWin32WidgetSet.AppInit(var ScreenInfo: TScreenInfo);
On Sun, 9 Jan 2011, Peter Williams wrote: Hi Lazarus list, I am proposing some changes to +procedure TWin32WidgetSet.AppInit(var ScreenInfo: TScreenInfo); in win32object.inc. These are changes to enable exception error handling which *should* be reported in file 'AppInit_backtrace.txt'. This was suggested as a general hint by someone else on this list. Refer to win32object.inc.diff (attached to #18448) This issue is now reported as: http://mantis.freepascal.org/view.php?id=18448 I looked at the patch, and I suggested some changes. I think these changes should be implemented prior to applying the patch. As it is now, the patch is very likely to cause serious problems in case of an exception. Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt mich...@freepascal.org wrote: On Sun, 9 Jan 2011, Graeme Geldenhuys wrote: 2011/1/9 Zaher Dirkey parm...@gmail.com: If you not use it, would you please make it as an option (new Platform). Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. I think it makes more sense to skip SDL and directly use the linux framebuffer. Eliminate a layer. You already have direct support for all other 'platforms' that SDL supports, so why add another (changing) dependency/point of failure? It may be initially harder, but will prove easier to maintain in the long run. It is for games, like The Mana Worldhttp://sourceforge.net/projects/themanaworld, have dialogs for options and login, we can use both SDL and show some forms. -- Zaher Dirkey -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Jan 9, 2011, at 1:40 PM, Zaher Dirkey wrote: On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt mich...@freepascal.org wrote: On Sun, 9 Jan 2011, Graeme Geldenhuys wrote: 2011/1/9 Zaher Dirkey parm...@gmail.com: If you not use it, would you please make it as an option (new Platform). Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. I think it makes more sense to skip SDL and directly use the linux framebuffer. Eliminate a layer. You already have direct support for all other 'platforms' that SDL supports, so why add another (changing) dependency/point of failure? It may be initially harder, but will prove easier to maintain in the long run. It is for games, like The Mana World, have dialogs for options and login, we can use both SDL and show some forms. This is also the reason why I started on a GLut/OpenGL backend for fpGUI. In the last weeks it has reached a point that some examples already work perfectly. Also I have done some preliminary tests on Mac and Linux (primary developing on Win32) which indicate it should run there without any issues. What still needs to be done it to analyze why certain widgets are not drawn correctly (fixing the backend and some subtle bugs in the core lib), fixing font drawing (which seems to have some major issues) and finally cleaning everything up. I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/ Regards, Darius-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On 9 January 2011 12:44, Michael Van Canneyt wrote: I think it makes more sense to skip SDL and directly use the linux framebuffer. The reasoning behind wanting to use SDL is so that I can target multiple platforms with one backend. Maybe not ideal, but a quick fix in supporting many platforms. Two platforms I am very interested in is Linux Framebuffer (so as to bypass the horrible X11) and Haiku (pretty amazing features and very fast). Closer to the time, I'll take a deeper look into each platforms API. As you said, writing for the platform directly and bypassing a extra layer/dependency might be the better approach in the long run. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Jan 9, 2011, at 4:16 PM, Graeme Geldenhuys wrote: On 9 January 2011 12:44, Michael Van Canneyt wrote: I think it makes more sense to skip SDL and directly use the linux framebuffer. The reasoning behind wanting to use SDL is so that I can target multiple platforms with one backend. Maybe not ideal, but a quick fix in supporting many platforms. Two platforms I am very interested in is Linux Framebuffer (so as to bypass the horrible X11) and Haiku (pretty amazing features and very fast). Closer to the time, I'll take a deeper look into each platforms API. As you said, writing for the platform directly and bypassing a extra layer/dependency might be the better approach in the long run. That's why we would need a common context library to be added to fpGUI in the long term. Darius-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
2011/1/9 Darius Blaszyk : I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/ I checked out that branch and tried to compile the fpgui_toolkit.lpk package in the 'gl' directory. Where do I find the freeglut unit which the compiler complains about. I'm using Ubuntu 8.04.4 and have installed all the glit and freeglut related packages and their *-dev packages. I'm using FPC 2.4.3 -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
2011/1/9 Darius Blaszyk : That's why we would need a common context library to be added to fpGUI in the long term. True. I guess if fpGUI still used a single handle per form design, things would have been a bit easier in this regard, but that would again make other things more difficult (drag-n-drop, docking etc comes to mind). On a side note: I still have no clue how Qt managed to make a smooth transition from one handle per widget to single handle per form design. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote: 2011/1/9 Darius Blaszyk : That's why we would need a common context library to be added to fpGUI in the long term. True. I guess if fpGUI still used a single handle per form design, things would have been a bit easier in this regard, but that would again make other things more difficult (drag-n-drop, docking etc comes to mind). On a side note: I still have no clue how Qt managed to make a smooth transition from one handle per widget to single handle per form design. Who said it was smooth ? =-) It's not because the application developer doesn't notice, that they didn't have problems with it's implementation... I suspect that their experience with Qt embedded (working on the framebuffer) would have helped. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On 9 January 2011 18:10, Michael Van Canneyt mich...@freepascal.org wrote: Who said it was smooth ? =-) By smooth, I meant the end-users (developers using Qt) did not notice anything different from there perspective. Re-reading the Qt blog on the subject, they do mention there was some black magic involved from their side - but again ensuring the end-user wouldn't notice anything different. http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ Looking at their first video clip though, I still have questions about why those widgets moved so much or momentarily disappear. I have never seen such bad flicker in fpGUI. Though X11's resizing performance (with or without compiz) is atrocious. The worst I've seen on any platform ever. Some days I still have mixed feeling about the move I made from single window handle per form to window handle per widget. At the time I was very new to X11 and GDI, and the original fpGUI code. Oh well, what's done is done. :) I suspect that their experience with Qt embedded (working on the framebuffer) would have helped. Probably so, because there they would have had to introduce the whole window handling and event system themselves. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Namespace
If units are namespaces, why not use them in widgets declarations, automatic, in Lazarus? When we droped a widget in a Form, ie a TEdit, the declarion would be like this: TForm1 = class(Form) Edit1: StdCtrls.TEdit; end; Why this? Well, we would not need to use prefixes in the names of our widgets. I could develop a widget called TEdit too, but using my own unit. All most developers use prefixes in yours classes and functions. Pascal not is C and don't need this. So, why do that? Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Sunday, 9. January 2011 17.24:03 Graeme Geldenhuys wrote: Some days I still have mixed feeling about the move I made from single window handle per form to window handle per widget. At the time I was very new to X11 and GDI, and the original fpGUI code. Oh well, what's done is done. :) I warned you. ;-) Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On 9 January 2011 18:34, Martin Schreiber wrote: I warned you. ;-) I did say mixed feelings, not regret. ;) I still think both methods have their pros and cons - depending on what you want to accomplish. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
Graeme Geldenhuys schrieb: On 8 January 2011 17:16, Hans-Peter Diettrich drdiettri...@aol.com wrote: What's the purpose of setting the mouse capture in the LCL? While nobody seems to know, I found that TSpltter uses mouse capture. MouseCapture (at least under fpGUI) is also used while the mouse button is down, eg on a TButton. For example (i think this works under LCL too). Click a TButton, and hold the mouse button down. Now move the mouse cursor outside the TButton bounds. The TButton should pop up (normal state again), and when you hove the mouse over the TButton, the mouse would be pressed again. That's questionable behaviour, that must be checked for compatibility with e.g. an DragManager. Since a DragManager has no HWND and cannot capture the mouse itself, a safe implementation would redirect all mouse and keyboard events to an dragging DragManager immediately, instead of delivering the events to the target control, in the hope that it will *in any case* forward the messages to the DragManager. At least I observed some weird behaviour of some controls, that do not check properly for a drag operation in progress. No such checks are required, and can be forgotten or implemented in a wrong way, when the event dispatcher already checks for a dragging operation in progress. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
09.01.2011 21:23, Hans-Peter Diettrich wrote: So much about theory. My question was about reasons for using mouse capture in LCL components, in detail the csCaptureMouse control state flag. So far its only reasonable use is in a TSplitter, to allow for fake moves (user feedback) and to obtain the final position of the splitter. I tried to reduce usage of csCaptureMouse in LCL components. It is used much less than a year before. or external event stops your mouse capture. Such external event can be for example switching task or another window require a mouse capture. The mouse is a shared resource, managed by the OS. I doubt that the mouse capture can be stolen by other processes. I.e. the owner of the mouse capture must release the capture, at some time (usually when the mouse button is released). No, mouse capture can be stolen by any process. DragManager must handle the CaptureChanged event in order to understand that capture it has was requested by other control and therefore it must stop the drag operation. NACK. The LCL components implement some weird behaviour, that can result in many changes of the mouse capture at the begin of a drag operation. These nearly unpredictable changes often cause the DragManager to stop dragging, in the current implementation. Once a control is dragged, there is no reason why the mouse capture should change until the end of the operation. When a control decides that dragging should stop, it should call DragManager.DragStop, everything else is insane. As result you will get a situation when application thinks that it dragges something but capture is not owned by the drag manager so mouse events are not tracked by it. Best regards, Paul Ishenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
09.01.2011 21:27, Hans-Peter Diettrich wrote: Since a DragManager has no HWND and cannot capture the mouse itself, a safe implementation would redirect all mouse and keyboard events to an dragging DragManager immediately, instead of delivering the events to the target control, in the hope that it will *in any case* forward the messages to the DragManager. When you drag from one window to another the space between windows is not owned by your application and therefore nobody forward messages to the drag manager. Best regards, Paul Ishenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Jan 9, 2011, at 4:47 PM, Graeme Geldenhuys wrote: 2011/1/9 Darius Blaszyk : I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/ I checked out that branch and tried to compile the fpgui_toolkit.lpk package in the 'gl' directory. Where do I find the freeglut unit which the compiler complains about. I'm using Ubuntu 8.04.4 and have installed all the glit and freeglut related packages and their *-dev packages. I'm using FPC 2.4.3 Oops, you'll need some stuff from another branch as well. I will update SVN and will let you know. My branch uses fcl-image and opengl from FPC 2.5.1 and some local modifications (mainly on freetype support). These will hopefully be merged bach to trunk once I finish and cleanup. Regards, Darius-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
On Jan 9, 2011, at 6:27 PM, Darius Blaszyk wrote: On Jan 9, 2011, at 4:47 PM, Graeme Geldenhuys wrote: 2011/1/9 Darius Blaszyk : I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/ I checked out that branch and tried to compile the fpgui_toolkit.lpk package in the 'gl' directory. Where do I find the freeglut unit which the compiler complains about. I'm using Ubuntu 8.04.4 and have installed all the glit and freeglut related packages and their *-dev packages. I'm using FPC 2.4.3 Oops, you'll need some stuff from another branch as well. I will update SVN and will let you know. My branch uses fcl-image and opengl from FPC 2.5.1 and some local modifications (mainly on freetype support). These will hopefully be merged bach to trunk once I finish and cleanup. I have added everything under a folder named external. Just add the two folders to the unit search path and it should compile. Regards, Darius -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Namespace
On Sun, Jan 9, 2011 at 2:57 PM, Andrew Brunner andrew.t.brun...@gmail.com wrote: I just started leveraging this fact in my project. The complaint I bring is that I don't want to use a class object. I want a dedicated NameSpace as a reserved word. ie.) NS_APP_FIELDS=class const VALUE1 = 'VAL1'; VALUE2 = 'Val2'; VALUE3 = 3; end; NS_APP_FIELDS=NameSpace const VALUE1 = 'VAL1'; VALUE2 = 'Val2'; VALUE3 = 3; end; I recognize it doesn't change much, but it would sure look more industry standardized if this would work. Even If in the interim, NameSpace:=Class ;-) somewhere... But to do it right there should be differences between classes and NameSpaces inside units. Whats even more impressive is the fact that this could be coupled with abstraction But back on direct topic, I often use unit names to specify which method I want explicitly accessed/used. In my project, sockets, byeArrays mean different things depending on where you are in specific a context. Having the option to clarify where the item is typed was offered way back in Delphi days. And what about procedures/functions? This problem isn't just about classes... In C, all the indentifiers would be unique, but not in Pascal. We have units (namespace) so, why use prefixes like TxyzEdit? Why not use, for example, xyz.TEdit (xyz would be the company, whatever) in all declarations? Wouldn't more readable? And will have less conflicts with others names of class too. Procedures and Functions, the same: xyz.foo() not xyzFoo() how the most developers like to do. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
Michael Van Canneyt wrote: Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. I think it makes more sense to skip SDL and directly use the linux framebuffer. Eliminate a layer. You already have direct support for all other 'platforms' that SDL supports, so why add another (changing) dependency/point of failure? It may be initially harder, but will prove easier to maintain in the long run. For what it's worth, I agree. If fpGUI goes directly to the framebuffer it will be usable with almost all Linux systems, while if it requires SDL there might turn out to be version requirements which prevent it from working in some cases. FPC and Lazarus are, by and large, pretty simple to build. Middleware such as SDL can be far more difficult because it can turn out to have a cascade of requirements, and in the past I've found things like TrueType to be particularly painful. -- 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
Re: [Lazarus] Namespace
Am 09.01.2011 16:11, schrieb Marcos Douglas: If units are namespaces, why not use them in widgets declarations, automatic, in Lazarus? [...] All most developers use prefixes in yours classes and functions. Pascal not is C and don't need this. So, why do that? Maybe the unit names should be shown in the keyword completition list. Then all namespace handling is easier. g Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Namespace
On Sun, Jan 9, 2011 at 2:25 PM, Marcos Douglas m...@delfire.net wrote: And what about procedures/functions? This problem isn't just about classes... In C, all the indentifiers would be unique, but not in Pascal. We have units (namespace) so, why use prefixes like TxyzEdit? Why not use, for example, xyz.TEdit (xyz would be the company, whatever) in all declarations? Wouldn't more readable? And will have less conflicts with others names of class too. Procedures and Functions, the same: xyz.foo() not xyzFoo() how the most developers like to do. We're going to have to get someone to work-around the duplicate identifiers problem too. But as it turns out with my case above, I ran into another problem. Identically named enums types didn't compile b/c they themselves were duplicated. I revised my code to employ nested consts instead of enums, this way I was able to group and simulate enums. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
FPC and Lazarus are, by and large, pretty simple to build. Middleware such as SDL can be far more difficult because it can turn out to have a cascade of requirements, and in the past I've found things like TrueType to be particularly painful. Hi Mark, Can you explain what your problems were with truetype? I'm using freetype for font rendering in the opengl backend but so far there were no main issues with the freetype bindings, apart from some issues (bugs?) in the fontmanager. Regards, Darius -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What are widgets in lazarus?
Graeme Geldenhuys schrieb: On a side note: I still have no clue how Qt managed to make a smooth transition from one handle per widget to single handle per form design. Where do you see problems? The OS has to track some global notification targets, for e.g. keyboard input or mouse capture. These targets are processes (or threads) in the first place. With no such global target (e.g. on an uncaptured mouse click) the screen/window manager can determine the target process from the information, stored with every window. That's why forms/windows always have a handle, assigned and used by the window manager of a platform. The determination of a closer target (e.g. control) is up to the application or library, that manages the layout of a window. Every application or library can freely define their own handles for every possible notification target, as appropriate to dispatch incoming notifications. The natural handle of every such target is the address of the data structure, that describes the target. The LCL can use the addresses of TComponent objects for its handles, while a widgetset can use the addresses of its equivalent data objects. Handles in general can be seen as pointers to data structures, or as indices into according pointer tables, that make sense only to the owner of those structures, within its own address space. E.g. GDI handles look much like indices into some (sparse) pointer array, consisting of areas for system wide objects (fonts...), and application or device context specific objects. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Namespace
Marcos Douglas schrieb: If units are namespaces, why not use them in widgets declarations, automatic, in Lazarus? When we droped a widget in a Form, ie a TEdit, the declarion would be like this: TForm1 = class(Form) Edit1: StdCtrls.TEdit; end; IMO control classes have to be registered, so that a compiled application can work independently from any namespace, unit or directory structure. That's why the first line above should read Form1 = class(TForm) where Form1 is the name of the form object, as stored in the object itself, and TForm is the ClassName in the TForm.ClassType (vulgo VMT). Why this? Well, we would not need to use prefixes in the names of our widgets. I could develop a widget called TEdit too, but using my own unit. All existing form objects are stored in Application.CustomForms[], and their controls in Form.Controls. Likewise the class names are usable via RTTI. Adding namespaces (or unit names) would require further table(s), that do not yet exist (except perhaps in debug info). All most developers use prefixes in yours classes and functions. Pascal not is C and don't need this. So, why do that? These qualifiers are resolved at compile time, they don't become part of the compiled application. When in some future time we'll have resources loadable at runtime, the names of the packages (DLL, so) will become important, but only to the resource loader, not to any existing table structure. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
Paul Ishenin schrieb: The mouse is a shared resource, managed by the OS. I doubt that the mouse capture can be stolen by other processes. I.e. the owner of the mouse capture must release the capture, at some time (usually when the mouse button is released). No, mouse capture can be stolen by any process. I doubt that, but not every OS is perfect ;-) At least the OS must notify the application that it lost mouse capture - this may be the only capture event that has to be handled by the DragManager. DragManager must handle the CaptureChanged event in order to understand that capture it has was requested by other control and therefore it must stop the drag operation. NACK. The LCL components implement some weird behaviour, that can result in many changes of the mouse capture at the begin of a drag operation. These nearly unpredictable changes often cause the DragManager to stop dragging, in the current implementation. Once a control is dragged, there is no reason why the mouse capture should change until the end of the operation. When a control decides that dragging should stop, it should call DragManager.DragStop, everything else is insane. As result you will get a situation when application thinks that it dragges something but capture is not owned by the drag manager so mouse events are not tracked by it. This cannot happen when the dragging condition is managed properly by the DragManager. Even if something goes really wrong, dragging stops at the next release of the mouse button, dispatched to the DragManager. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Purpose of MouseCapture?
Paul Ishenin schrieb: Since a DragManager has no HWND and cannot capture the mouse itself, a safe implementation would redirect all mouse and keyboard events to an dragging DragManager immediately, instead of delivering the events to the target control, in the hope that it will *in any case* forward the messages to the DragManager. When you drag from one window to another the space between windows is not owned by your application and therefore nobody forward messages to the drag manager. The mouse must be captured when dragging starts, of course. But afterwards all mouse messages must be handled *only* by the DragManager, until dragging is finished. Please note that I never said that a mouse capture is of no use at all. But it must be handled properly, what is not the case in the current LCL implementation. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] fpGUI + SDL versus Lazarus + SDL -- pros and cons
Hi Graeme and all, Subject edited. Cross posted to Lazarus and Free Pascal lists. On 01/09/2011 09:08 PM, Graeme Geldenhuys wrote: 2011/1/9 Zaher Dirkeyparm...@gmail.com: If you not use it, would you please make it as an option (new Platform). Yes, it will definitely be a new platform. fpGUI would then have eg: GDI, X11, SDL etc. as backends. Can fpGUI *currently* be used with (JEDI-)SDL? Also, what the sources of the latest SDL libraries and demos for Lazarus? I could only find (and download) JEDI-SDLv1.0.zip, which is for Delphi and someone else here (on the Lazarus list) offered to send me the latest version. Who is the administrator for the JEDI-SDL official releases? Are you doing your job, or voluntary role? :-) If you say Yes then why is the latest version of JEDI-SDL not currently available for download by the public? Is the latest Lazarus Free Pascal version of JEDI-SDL only available via the peer group of it's users? :-( If that is true then it is time that a new official version is published on Source Forge (currently at v1.0) for Delphi only. What is the difference between using fpGUI with SDL and Lazarus with SDL? Does the fpGUI + SDL create smaller binaries (on linux) versus Lazarus + SDL? Or are the other pros and cons? I have a Lazarus and SDL game application and I was not aware of the option of using fpGUI + SDL. Advantages and disadvantages, please? pew -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Nested Classes used as Namespace Issue
type ns=class Type Vendor=class Const id= ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI + SDL versus Lazarus + SDL -- pros and cons
Hi, Can fpGUI *currently* be used with (JEDI-)SDL? You can use pretty much any library with fpGUI, just like you can with any FPC based application. What the fpGUI+SDL discussion was about, is the various backends fpGUI supports for drawing its widgets. Currently fpGUI talks to X11 (under Linux/*BSD) and GDI (under Windows/WinCE) to get window management and painting API's. The SDL discussion was about extending the fpGUI code with a new SDL backend - where SDL does the painting of widgets, forms etc. I believe what you are referring to is the following: fpGUI, just like LCL, can also supply a painting canvas to libraries like Cairo, OpenGL, SDL etc to draw onto. This is currently possible without difficulty. In fact, I have already seen a few fpGUI apps using Cairo and SDL canvas's to do some painting - the main app is standard fpGUI widgets using X11 or GDI, and then some window or widget contains the Cairo or SDL painting output. What is the difference between using fpGUI with SDL and Lazarus with SDL? No difference. Does the fpGUI + SDL create smaller binaries (on linux) versus Lazarus + SDL? Or are the other pros and cons? Overall fpGUI application do have smaller binaries than Lazarus apps, irrespective if they use SDL or not. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Nested Classes used as Namespace Issue
10.01.2011 11:43, Andrew Brunner wrote: type ns=class Type Vendor=class Const id= ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos? Codetools does not recognise the nested class syntax yet. There was already a feature request. Best regards, Paul Ishenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
