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
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
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
// examp
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 Dirkey:
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 ha
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* f
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 an
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 tha
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 capt
> 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
On Sun, Jan 9, 2011 at 2:25 PM, Marcos Douglas 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
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
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
On Sun, Jan 9, 2011 at 2:57 PM, Andrew Brunner
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
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 tri
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' direc
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 tha
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
Graeme Geldenhuys schrieb:
On 8 January 2011 17:16, Hans-Peter Diettrich 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, e
Paul Ishenin schrieb:
08.01.2011 22:16, Hans-Peter Diettrich wrote:
Hans-Peter Diettrich schrieb:
What's the purpose of setting the mouse capture in the LCL?
While nobody seems to know, I found that TSpltter uses mouse capture.
Sorry, I did not notice the initial mail.
So the DragManager s
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 =
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 -
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.
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
widget
On 9 January 2011 18:10, Michael Van Canneyt 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 t
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
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 (
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 comp
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 b
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 platfor
On Jan 9, 2011, at 1:40 PM, Zaher Dirkey wrote:
> On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt
> wrote:
>
>
> On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
>
> 2011/1/9 Zaher Dirkey :
>
> If you not use it, would you please make it as an option (new Platform).
>
> Yes, it will defin
On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt wrote:
>
>
> On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
>
> 2011/1/9 Zaher Dirkey :
>>
>>>
>>> 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 h
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'. T
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
2011/1/9 Zaher Dirkey :
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
On 8 January 2011 17:16, Hans-Peter Diettrich 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 examp
2011/1/9 Zaher Dirkey :
>
> 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-
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
36 matches
Mail list logo