Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]

[Burkhard Carstens]

Am Donnerstag, 31. Januar 2008 07:39 schrieb A.J. Venter:
[...]
> > If not, maybe hooking into the surrounding forms events would
> > suffice.
>
> This was my first idea, but unfortunately, it doesn't work at all.
> The reason is that forms only get keyboard focus onActivate and even
> then they only keep it if there is no focusable components - else
> it's hardpassed to the component with focus preference.  Running
> Form.SetFocus throws an exception (Form cannot take focus) - [why is
> it there if it cannot be called ?]
> If there is a way to make a form take keyboard focus to itself so
> it's keyEvents work even if there are focusable components on it then
> I haven't found it yet.

Isn't TForm.KeyPreview meant for exactly this purpose? Just set it to 
true and your form should get the KeyEvents regardless of which 
component has the focus .. off course this still only works if the form 
is active ..

regards
 Burkhard

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Christian U.]

"Nero for Linux v3" is one such case. Linux has loads of CD/DVD
writing software, but nothing I like, or can say feels polished (yes
even K3b doesn't do it for me).  "Nero for Linux" just works and well
worth the money.
  

Never tried it, never needed it. Nautilus works just great to burn CD´s.
K3B is also OK.


"Total Commander" is another such case. Yes I run 99.9% of the times
Linux, but TC works perfectly via Wine. TC just has such cool features
and makes file management a breeze. Other than Midnight Commander, no
open source tool comes even close.
  
I use it on windows in wine its to ugly for me. MC has a lot of features 
more.


I like LazReport and support it, no need for an commercial Tool where i 
never have the chance to hunt bugs or

take a look in the source to get closer to an problem.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Win32 compilation error : Import library not found for libz

[Graeme Geldenhuys]

Are you using/linking a external (.dll or .so) or are you using the
zlib unit  (implementation in object pascal) included with FPC?

Regards,
  - Graeme -


On 30/01/2008, Dominique Louis <[EMAIL PROTECTED]> wrote:
> Hi all,
>I've just been trying to compile some code that makes use of Zlib and
> when I try to compile it from within Lazarus I get the following error
>
> Error: Import library not found for libz
>
> at the linking stage. It's the only thing stopping it from linking.
>
> Is this a bug in FPC 2.2.1 or am I missing the libz.o file?
>
> I'm using the snapshot from 27th of Jan 2008, if that makes any difference.
>
> Thanks,
>
>
> Dominique.
>
> _
>  To unsubscribe: mail [EMAIL PROTECTED] with
> "unsubscribe" as the Subject
>archives at http://www.lazarus.freepascal.org/mailarchives
>


-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

ReRe: [lazarus] ScrollBox scrolling problem situation

[Andrey Gusev]

Damn, wedged on Ctrl+V.
==

* Micha Nelissen <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 22:27:36
+0100]:

Andrey Gusev wrote:
> - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);

No. ORect.Left is offset from Win32 -> LCL. So if LCL draws at (0,0)

it

should actually be at (ORect.Left, ORect.Top), so the code is correct.


Opposite scrolling of TPaintBox mist be explanable, anyway.
Ether by message proccessing bug, or TPaintBox implementation.

That's unintelligible (now) to me, why Panel being placed together
with TPaintBox react to scroll otherwise then without him ?
Get project from last my post in  "[lazarus] Found serious bug in win32 
interface #2" thread.



> With these changes TScroolBox behaviour is almost adequate.
> Some problems with child controls positioning when scroll still
exists.

Hint: try looking at GetLCLClientBoundsOffset (if you didn't already).


Thanks fo hint, tha't is was missing part, to my investigations.


I am not sure what bug you want to fix?


My principal trouble is http://bugs.freepascal.org/view.php?id=10471
Mattias Gaertner have told way:


The problem is, that at the moment the win32 interface moves the childs
instead of moving the client area. This operation is not atomic, that
means, each child move creates messages. It is nearly impossible to
make this operation atomic platform independently. That's why instead
all widgetsets should instead move the 'client area'. This means the
childs should be put on an internal widget - the 'client area widget'.
Scrolling means then to simply move the client area widget.
So, it is needed that TWin32WSScrollingWinControl creates an internal
widget and put its childs on this widget. That's all.
The winapi part is not hard. The hardest part is to understand the
win32 interface and fix all places, where this might be relevant.


I simply fairly try to understand all up to the end.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]

[A.J. Venter]

Me too, I'd like to play around and maybe do something useful (or
funny :) with it. It could at least be put on the CCR if not into
lazarus distribution itself.

That may be a good start. I'll submit it to the CCR as soon as I finish 1.0
Please note I combined two posts below:


How about a middle ground: create a new TKeyboardEvents unit using

code from one of the components that already has it. Yes you will have
the initial code duplication in creating the unit in the first place,
but this would allow adding keyboard events to other controls simply
by inheriting from the base class. In fact, this may be something that
the LCL could use and incorporate itself in the future, if you get it
working property.
I'm not sure about this one - as it would mean anything that needs 
keyboardevents cannot be descended from anything else (e.g. a 
customControl or it's descendents like tpicture).
However it might be possible to create a small component 
TKeyboardListener or something that DOES have these events, can take 
focus but isn't actually VISIBLE(is this last bit possible ? Perhaps if 
you hardcode it's width and height properties to be locked to 0) . Then 
anybody who needs to capture keyEvents globally would be able to drop 
one on a form and use it, and components like TDoubleBuffer could just 
instantiate one (or hook into one through a property - perhaps better).


This would actually I think be an incredibly useful GENERAL add-on to 
the LCL as it would create a platform independent way of doing what 
windows coders do with callbacks and hooks. Somebody with deeper LCL 
knowledge want to comment on this ?


I haven't looked into the sources deeply, but can't you override some
OnKeyXxx-methods to get the key events?
I don't think there ARE any to overwrite- perhaps in the parent class 
for TCustomControl, but they aren't republished. If you use override 
though - you may as well rewrite them as you'll need to do the same work 
anyway - it doesn't solve the clutter-and-duplicate problem.


If not, maybe hooking into the surrounding forms events would suffice.
This was my first idea, but unfortunately, it doesn't work at all. The 
reason is that forms only get keyboard focus onActivate and even then 
they only keep it if there is no focusable components - else it's 
hardpassed to the component with focus preference.  Running 
Form.SetFocus throws an exception (Form cannot take focus) - [why is it 
there if it cannot be called ?]
If there is a way to make a form take keyboard focus to itself so it's 
keyEvents work even if there are focusable components on it then I 
haven't found it yet.


Ciao
A.J.
--
"Any sufficiently advanced technology is indistinguishable from magic" - 
Clarke's law
"Any technology that is distinguishable from magic is insufficiently 
advanced" -Gehm's corollary
"Any technologist that is distinguishable from a magician is 
insufficiently advanced" - My corollary

The worlds worst webcomic: http://silentcoder.co.za/scartoonz
The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za

begin:vcard
fn:AJ Venter
n:Venter;AJ
org:Global Pact Trading Pty. Ltd.;OutKast Solutions
email;internet:[EMAIL PROTECTED]
title:Director of Product Development
tel;work:+27 21 554 5059
tel;fax:+27 11 252 9197
tel;cell:+27 83 455 9978
url:http://www.outkastsolutions.co.za
version:2.1
end:vcard

Re: [lazarus] Found serious bug in win32 interface

[Andrey Gusev]

* Micha Nelissen <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 22:27:36 
+0100]:

Andrey Gusev wrote:
> -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);

No. ORect.Left is offset from Win32 -> LCL. So if LCL draws at (0,0) 

it

should actually be at (ORect.Left, ORect.Top), so the code is correct.


Opposite scrolling of TPaintBox mist be explanable, anyway.
Ether by message proccessing bug, or TPaintBox implementation.

That's unintelligible (now) to me, why Panel being placed together
with TPaintBox react to scroll otherwise then without him ?
Get project from 
http://mail.rambler.ru/mail/mail.cgi?mode=obj;mbox=INBOX%26r%3D5f6a;what=6827, 
my post



> With these changes TScroolBox behaviour is almost adequate.
> Some problems with child controls positioning when scroll still
exists.

Hint: try looking at GetLCLClientBoundsOffset (if you didn't already).


Thanks fo hint, tha't is was missing part, to my investigations.


I am not sure what bug you want to fix?


My principal trouble is http://bugs.freepascal.org/view.php?id=10471
Mattias Gaertner have told way, 
http://mail.rambler.ru/mail/mail.cgi?mode=obj;mbox=INBOX%26r%3D5f6a;what=4702

I simply fairly try to understand all up to the end.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Graeme Geldenhuys]

On 30/01/2008, Christian U. <[EMAIL PROTECTED]> wrote:
> >
> I dont like commercial products in combination with lazarus so i spend
> my time to make lazreport bedder when i want it and dont send mails to
> obscure commercial suppliers.

I don't know of any comercial products for  Lazarus, so I assume (yes
I know I shouldn't) you are talking about commecial software with open
source software in general.

I guess this is where I differ from most (that I know of) open source
users. I'm a big open source fan, but I have absolutly no problem in
buying commercial software if it's of high quality and does what I
need. Why can't the two sides work together? As for high quality
software...

"Nero for Linux v3" is one such case. Linux has loads of CD/DVD
writing software, but nothing I like, or can say feels polished (yes
even K3b doesn't do it for me).  "Nero for Linux" just works and well
worth the money.

"Total Commander" is another such case. Yes I run 99.9% of the times
Linux, but TC works perfectly via Wine. TC just has such cool features
and makes file management a breeze. Other than Midnight Commander, no
open source tool comes even close.

"Beyond Compare 2" is another such case.  And the list goes on

PS:
  If you don't know any of the products I mentioned, I recommend you
Google them.

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

[Andrey Gusev]

* Luiz Americo Pereira Camara <[EMAIL PROTECTED]> [Thu, 31 Jan 2008 
01:16:58 -0300]:

Andrey Gusev wrote:
> * Mattias Gärtner <[EMAIL PROTECTED]> [Wed, 30 Jan 2008
> 18:45:57 +0100]:
>> Zitat von Andrey Gusev <[EMAIL PROTECTED]>:
>>
>> > --- interfaces/win32/win32callback.inc (revision 13905)
>> > +++ interfaces/win32/win32callback.inc (working copy)
>> >  @@ -504,7 +504,7 @@
>> > if (ControlDC = 0) or not needParentPaint then
>> >  begin
>> >  DCIndex := Windows.SaveDC(PaintMsg.DC);
>> >  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
>> > + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
>> >  {$ifdef DEBUG_DOUBLEBUFFER}
>> >  Windows.GetClipBox(PaintMsg.DC, ClipBox);
>> > DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
>> > with
>> > clipping rect (',
>> >
>> > I can provide application that's confirm my rightfulness.
>> > But i don't wish to do it, until all child-control negative 

effects

>> will
>> > debugged (by me), it need to LazReport designer functionality.
>> > If wished, try to place oversized TPaintBox on TScrollBox and try
it
>> to
>> > scroll (with above patch applied).
>>
>> It might improve the situation, but I guess it will not fix the 

whole

>> problem.
>> See here:
>> http://wiki.lazarus.freepascal.org/Win32/64_Interface
>
> It was said, about intermeditate layer, earlier (by You).
> Also, it implementation started in win32wsfrorms, rudimentary state.
> But observed, with above correction, child controls scrolls 

correctly,

> except
> page and line messages processing, which brings some negative shift,
> for childs.
> Undoubtedly, we can force to work existing variant, a few various
> methods can be invented
> (twice MoveWindowOrg for example).
> But pointed bug is nice explaination (and chance to eliminate) the
> strange opposite scrolling behaviour.
> see http://bugs.freepascal.org/view.php?id=10400,
> also observation, described in my #16900 reply,
> http://bugs.freepascal.org/view.php?id=10471,
> correspond to pointed bug presence.

Hi, do you have one or two small proof of concept LCL application that
shows the problem? (works in gtk fails in win32).
If you have please send me or post in the bugtracker/here.
I will take a look.


See attachement.
Form2 & Form3 demonstrates problems with tabbed controls, that brings by 
above patch,

it implementations must be corrected, as i mean.



ttt.TGZ
Description: GNU Unix tar archive

Re: [lazarus] Cgi / PowUtils / FastCgi

[Bee]

I second that. powutils work great.  We ported a GUI app to CGI and
could reuse a lot of code because everything is still written in
Object Pascal.  So far we are getting away with opening and closing
database connections the whole time, but I am sure if we start using
stress tests we would have to make a plan.  I heard Apache Modules
would be a possible solution to the database connection pool.


For more OOPish solution, someone make a fork of Powtils and wrap it in 
OOP framework. It does it all, connection pooling, template engine, etc. 
But, I found it too complicated to use (remind me to Java) so I stick to 
Powutils for the moment until FPC's CGI framework got stable. ;)


-Bee-

has Bee.ography at:
http://beeography.wordpress.com

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

[Luiz Americo Pereira Camara]

Andrey Gusev wrote:
* Mattias Gärtner <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 
18:45:57 +0100]:

Zitat von Andrey Gusev <[EMAIL PROTECTED]>:

> --- interfaces/win32/win32callback.inc (revision 13905)
> +++ interfaces/win32/win32callback.inc (working copy)
>  @@ -504,7 +504,7 @@
> if (ControlDC = 0) or not needParentPaint then
>  begin
>  DCIndex := Windows.SaveDC(PaintMsg.DC);
>  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
>  {$ifdef DEBUG_DOUBLEBUFFER}
>  Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
> with
> clipping rect (',
>
> I can provide application that's confirm my rightfulness.
> But i don't wish to do it, until all child-control negative effects
will
> debugged (by me), it need to LazReport designer functionality.
> If wished, try to place oversized TPaintBox on TScrollBox and try it
to
> scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole
problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, 
for childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented

(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.

see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,

correspond to pointed bug presence.


Hi, do you have one or two small proof of concept LCL application that 
shows the problem? (works in gtk fails in win32).

If you have please send me or post in the bugtracker/here.
I will take a look.

Luiz

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Giuliano Colla]

Marco van de Voort ha scritto:

On Wed, Jan 30, 2008 at 08:36:00PM +0100, Giuliano Colla wrote:
  

OK, I understand your issue now.  Simple solution is:  Always do a
Build All.  :-)
  
By what means do you suggest to obtain that from everybody: moral suasion, 
menaces, salary cut, spanking or other corporal punishment? :-)



Much worse. Threathen to introduce formal procedures.

  
Mmmmh. Then I too would be forced to follow them! They'll never believe 
it! :-(
Better dig into Codetools unexplored land and find a way to insert a -B 
in Compiler Options!


Giuliano

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

[Marc Weustink]

Andrey Gusev wrote:

* Paul Ishenin <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
> That:
> --- interfaces/win32/win32callback.inc(revision 13905)
> +++ interfaces/win32/win32callback.inc(working copy)
> @@ -504,7 +504,7 @@
>   if (ControlDC = 0) or not needParentPaint then
>   begin
> DCIndex := Windows.SaveDC(PaintMsg.DC);
> -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
> {$ifdef DEBUG_DOUBLEBUFFER}
> Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

> clipping rect (',
>

 



Please try to build ide with your changes and you'll see nice effects 

:)




I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked
tabular-components on top of so fundamental bug ???


This is recently changed. Initially the code had a similar behaviour as 
delphi. It became clear that only scrolling in win32 would work like the 
old way and that all other widgetsets had to add heaps of code.
So scrolling changed, however all widgetsets need to get adapted to the 
new situation.


Marc

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Marc Weustink]

Giuliano Colla wrote:

Vincent Snijders ha scritto:

Giuliano Colla schreef:

Vincent Snijders ha scritto:

Graeme Geldenhuys schreef:

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:

You don't need ifdefs. You need to fix the differences.

Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is 
cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main 
form is enabled.


That is why there different widgetset backends too, not just to 
create different

widgets, but also to make them behave consistent.


But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.



Don't assume, research.

Not convinced,


GTK1 implementation of TMemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_editable_insert_text(PGtkEditable(widget), char,
   NewTextLength - CutLength, Position);
end;

g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text');

GTK2 implementation of Tmemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_text_buffer_insert(TextBuffer, StartIter, TheText, 
NewTextLength - CutLength);

end;

g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 
'insert-text');


GTK2 scrolls in order to show the text just inserted, GTK1 doesn't.

Convinced now?


Convinced, that you did some research: yes.

Convinced, that you did enough research: no.

Convinced, that scrolling the text after inserting text is agains the 
native behaviour of the native widgetset: no, not at all.


IMO, the LCL should give the application users a native look and feel 
using the native components as much as possible. At this moment, we 
are failing in this respect with our current implementation of the 
Treeview and the Toolbar, for example, since they are drawn by the LCL 
and not by the widget set. This will probably change in the future, 
keeping the current Treeview as TLCLTreeView or something like that.


The LCL should give the application developer a consistent (VCL 
compatible) interface to accomplish that.


In this case when you append or insert text the application developer 
expects that gtk1 and gtk2 (and all widget set) do the same thing: 
either scroll to end or leave the cursor on the current position. I 
don't think that this scrolling (or not scrolling) can be considered 
intrisically part of a widget set.


Suppose we decide that a widget should scroll when adding  line to a 
LCL TMemo should scroll that line into view, then all widgetset should 
do that. The gtk1 implementation should add extra code to accomplish 
that.


Suppose we decide that a widget should not scroll when adding  line to 
a LCL TMemo should scroll that line into view, then all widgetset 
should not do that. The gtk2 implementation should record the current 
position and add extra code to accomplish to keep the cursor on the 
current position.


I would sugest to fix the gtk1 implementation.

I hope this is clear now, if not, feel free to ask for clarification.



What you say is clear, and I do agree with you. LCL should provide 
consistent behavior across widgetsets. Maybe I can disagree on what's 
the best way (i.e. minimum work-best result) to achieve this result, but 
that's another matter, and it's up to you, after all. I can just provide 
my point of view as a contribute to the discussion.


But when I see other developers say exactly the opposite, i.e. that LCL 
should provide "native" behavior, and maintain that some properties 
shouldn't be implemented in some widgesets because they're not natively 
available, then I get confused.


Native widgets <> native behaviour. The LCL adds functionality to native 
widgets so a LCL user wil benefit from that and will het the same 
behaviour. (also the VCL added some different behaviour to win32 widgets)
On case by case base it is decided if a certain behaviour is compatible 
with delphi, is better than delphi or is behaving like most widgetsets.
For scrolling after a line is added, I don't know. Personally I hate it 
when a memo gets updated and I want to read the contents the same time.


Marc



Giuliano



_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Marco van de Voort]

On Wed, Jan 30, 2008 at 08:36:00PM +0100, Giuliano Colla wrote:
>> OK, I understand your issue now.  Simple solution is:  Always do a
>> Build All.  :-)
> 
> By what means do you suggest to obtain that from everybody: moral suasion, 
> menaces, salary cut, spanking or other corporal punishment? :-)

Much worse. Threathen to introduce formal procedures.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

[Micha Nelissen]

Andrey Gusev wrote:
> -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);

No. ORect.Left is offset from Win32 -> LCL. So if LCL draws at (0,0) it
should actually be at (ORect.Left, ORect.Top), so the code is correct.

> With these changes TScroolBox behaviour is almost adequate.
> Some problems with child controls positioning when scroll still exists.

Hint: try looking at GetLCLClientBoundsOffset (if you didn't already).

I am not sure what bug you want to fix?

Micha

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Giuliano Colla]

Vincent Snijders ha scritto:

Giuliano Colla schreef:

Vincent Snijders ha scritto:

Graeme Geldenhuys schreef:

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:

You don't need ifdefs. You need to fix the differences.

Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is 
cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main form 
is enabled.


That is why there different widgetset backends too, not just to 
create different

widgets, but also to make them behave consistent.


But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.



Don't assume, research.

Not convinced,


GTK1 implementation of TMemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_editable_insert_text(PGtkEditable(widget), char,
   NewTextLength - CutLength, Position);
end;

g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text');

GTK2 implementation of Tmemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_text_buffer_insert(TextBuffer, StartIter, TheText, 
NewTextLength - CutLength);

end;

g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 
'insert-text');


GTK2 scrolls in order to show the text just inserted, GTK1 doesn't.

Convinced now?


Convinced, that you did some research: yes.

Convinced, that you did enough research: no.

Convinced, that scrolling the text after inserting text is agains the 
native behaviour of the native widgetset: no, not at all.


IMO, the LCL should give the application users a native look and feel 
using the native components as much as possible. At this moment, we are 
failing in this respect with our current implementation of the Treeview 
and the Toolbar, for example, since they are drawn by the LCL and not by 
the widget set. This will probably change in the future, keeping the 
current Treeview as TLCLTreeView or something like that.


The LCL should give the application developer a consistent (VCL 
compatible) interface to accomplish that.


In this case when you append or insert text the application developer 
expects that gtk1 and gtk2 (and all widget set) do the same thing: 
either scroll to end or leave the cursor on the current position. I 
don't think that this scrolling (or not scrolling) can be considered 
intrisically part of a widget set.


Suppose we decide that a widget should scroll when adding  line to a LCL 
TMemo should scroll that line into view, then all widgetset should do 
that. The gtk1 implementation should add extra code to accomplish that.


Suppose we decide that a widget should not scroll when adding  line to a 
LCL TMemo should scroll that line into view, then all widgetset should 
not do that. The gtk2 implementation should record the current position 
and add extra code to accomplish to keep the cursor on the current 
position.


I would sugest to fix the gtk1 implementation.

I hope this is clear now, if not, feel free to ask for clarification.



What you say is clear, and I do agree with you. LCL should provide 
consistent behavior across widgetsets. Maybe I can disagree on what's 
the best way (i.e. minimum work-best result) to achieve this result, but 
that's another matter, and it's up to you, after all. I can just provide 
my point of view as a contribute to the discussion.


But when I see other developers say exactly the opposite, i.e. that LCL 
should provide "native" behavior, and maintain that some properties 
shouldn't be implemented in some widgesets because they're not natively 
available, then I get confused.


Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

RE: [lazarus] Found serious bug in win32 interface #2

[Andrew Brunner]

What I don't understand is why would you need to implement a localized
ScrollWindow(..) to provide the effect of Scrolling a window.

For the sake simplicity Windows scrolls a window and takes care of all
children in that window.  

These aren't questions that need answers.  I'm just pointing out that MS
Windows sufficiently offers API to scroll a window with children.  I just
wanted to point that out.

Thanks.



-Original Message-
From: Andrey Gusev [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 3:48 PM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Found serious bug in win32 interface #2

* Mattias Gärtner <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 
18:45:57 +0100]:
> Zitat von Andrey Gusev <[EMAIL PROTECTED]>:
>
> > --- interfaces/win32/win32callback.inc (revision 13905)
> > +++ interfaces/win32/win32callback.inc (working copy)
> >  @@ -504,7 +504,7 @@
> > if (ControlDC = 0) or not needParentPaint then
> >  begin
> >  DCIndex := Windows.SaveDC(PaintMsg.DC);
> >  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> > + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
> >  {$ifdef DEBUG_DOUBLEBUFFER}
> >  Windows.GetClipBox(PaintMsg.DC, ClipBox);
> > DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
> > with
> > clipping rect (',
> >
> > I can provide application that's confirm my rightfulness.
> > But i don't wish to do it, until all child-control negative effects
> will
> > debugged (by me), it need to LazReport designer functionality.
> > If wished, try to place oversized TPaintBox on TScrollBox and try it
> to
> > scroll (with above patch applied).
>
> It might improve the situation, but I guess it will not fix the whole
> problem.
> See here:
> http://wiki.lazarus.freepascal.org/Win32/64_Interface

It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, for 
childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented
(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.
see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,
correspond to pointed bug presence.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

[Andrey Gusev]

* Mattias Gärtner <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 
18:45:57 +0100]:

Zitat von Andrey Gusev <[EMAIL PROTECTED]>:

> --- interfaces/win32/win32callback.inc (revision 13905)
> +++ interfaces/win32/win32callback.inc (working copy)
>  @@ -504,7 +504,7 @@
> if (ControlDC = 0) or not needParentPaint then
>  begin
>  DCIndex := Windows.SaveDC(PaintMsg.DC);
>  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
>  {$ifdef DEBUG_DOUBLEBUFFER}
>  Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
> with
> clipping rect (',
>
> I can provide application that's confirm my rightfulness.
> But i don't wish to do it, until all child-control negative effects
will
> debugged (by me), it need to LazReport designer functionality.
> If wished, try to place oversized TPaintBox on TScrollBox and try it
to
> scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole
problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, for 
childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented

(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.

see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,

correspond to pointed bug presence.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Win32 compilation error : Import library not found for libz

[Dominique Louis]

Hi all,
  I've just been trying to compile some code that makes use of Zlib and 
when I try to compile it from within Lazarus I get the following error


Error: Import library not found for libz

at the linking stage. It's the only thing stopping it from linking.

Is this a bug in FPC 2.2.1 or am I missing the libz.o file?

I'm using the snapshot from 27th of Jan 2008, if that makes any difference.

Thanks,


Dominique.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Vincent Snijders]

Giuliano Colla schreef:

Vincent Snijders ha scritto:

Graeme Geldenhuys schreef:

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:

You don't need ifdefs. You need to fix the differences.

Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is 
cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main form 
is enabled.


That is why there different widgetset backends too, not just to 
create different

widgets, but also to make them behave consistent.


But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.



Don't assume, research.

Not convinced,


GTK1 implementation of TMemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_editable_insert_text(PGtkEditable(widget), char,
   NewTextLength - CutLength, Position);
end;

g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text');

GTK2 implementation of Tmemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_text_buffer_insert(TextBuffer, StartIter, TheText, 
NewTextLength - CutLength);

end;

g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text');

GTK2 scrolls in order to show the text just inserted, GTK1 doesn't.

Convinced now?


Convinced, that you did some research: yes.

Convinced, that you did enough research: no.

Convinced, that scrolling the text after inserting text is agains the 
native behaviour of the native widgetset: no, not at all.


IMO, the LCL should give the application users a native look and feel 
using the native components as much as possible. At this moment, we are 
failing in this respect with our current implementation of the Treeview 
and the Toolbar, for example, since they are drawn by the LCL and not by 
the widget set. This will probably change in the future, keeping the 
current Treeview as TLCLTreeView or something like that.


The LCL should give the application developer a consistent (VCL 
compatible) interface to accomplish that.


In this case when you append or insert text the application developer 
expects that gtk1 and gtk2 (and all widget set) do the same thing: 
either scroll to end or leave the cursor on the current position. I 
don't think that this scrolling (or not scrolling) can be considered 
intrisically part of a widget set.


Suppose we decide that a widget should scroll when adding  line to a LCL 
TMemo should scroll that line into view, then all widgetset should do 
that. The gtk1 implementation should add extra code to accomplish that.


Suppose we decide that a widget should not scroll when adding  line to a 
LCL TMemo should scroll that line into view, then all widgetset should 
not do that. The gtk2 implementation should record the current position 
and add extra code to accomplish to keep the cursor on the current position.


I would sugest to fix the gtk1 implementation.

I hope this is clear now, if not, feel free to ask for clarification.

Vincent




_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Giuliano Colla]

Vincent Snijders ha scritto:

Graeme Geldenhuys schreef:

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:

You don't need ifdefs. You need to fix the differences.

Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is 
cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main form 
is enabled.


That is why there different widgetset backends too, not just to 
create different

widgets, but also to make them behave consistent.


But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.



Don't assume, research.

Not convinced,


GTK1 implementation of TMemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_editable_insert_text(PGtkEditable(widget), char,
   NewTextLength - CutLength, Position);
end;

g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text');

GTK2 implementation of Tmemo InsertText:

if NewTextLength - CutLength > 0 then begin
  gtk_text_buffer_insert(TextBuffer, StartIter, TheText, 
NewTextLength - CutLength);

end;

g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text');

GTK2 scrolls in order to show the text just inserted, GTK1 doesn't.

Convinced now?

Giuliano


--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Giuliano Colla]

Graeme Geldenhuys ha scritto:

On 30/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote:

If one has last built project1, and then does some editing and just
compiles (instead of building) project2, project2 may inherit units
which where compiled with project1 conditionals, generating a mix-up,
which may go undetected.

That's why I was looking for a way to avoid this problem.


OK, I understand your issue now.  Simple solution is:  Always do a
Build All.  :-)



By what means do you suggest to obtain that from everybody: moral 
suasion, menaces, salary cut, spanking or other corporal punishment? :-)



Create a keyboard shortcut for Build All, or use Ctrl+F9 for Build All
instead of the default compiler (I use Build = Ctrl+F9  and Build All
= Shift+Ctrl+F9).  Alternatively, install the Editor Toolbar package,
add all the different build and compile functions to the toolbar.  Now
everything is one click away!

Quick and easy solution... :-)



See above! However a Toolbar shortcut might be an incentive. Thanks for 
the hint.


Giuliano


--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Christian U.]

Graeme Geldenhuys schrieb:

While you are all busy talking about reports.  Why don't each of you
fire off a email to the creators of ReportBuilder.  They have a
awesome reporting tool for Delphi. You could use it equally well from
code and designer plus it had a built-in script language. You could
report from datasets and pretty much any other type of data like
Objects etc...

I emailed them a few months back... They said they are keeping an eye
on Free Pascal and the Lazarus projects and would definately evalute
it if there was enough interest.
  
I dont like commercial products in combination with lazarus so i spend 
my time to make lazreport bedder when i want it and dont send mails to 
obscure commercial suppliers.



Regards,
  - Graeme -


On 30/01/2008, Andreas Berger <[EMAIL PROTECTED]> wrote:
  

Could I have some idea as to what you are using to generate reports? Do
you use internal report generators like :LazReport or external ones?
LazReport seems to be an incomplete implementation of FreeReport which
is also way outdated. Can some one please give me some hints.

Thanks,
Andreas



_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

  


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Wider use case for gamepack ?

[Marc Santhoff]

Am Mittwoch, den 30.01.2008, 17:05 +0200 schrieb A.J. Venter:
> > Well, *I* think it's very cool. In fact, when I get back around to my
> > life-long pet project (a chess engine extraordinaire :) this will be
> > the first library I look at for the board UI.

Me too, I'd like to play around and maybe do something useful (or
funny :) with it. It could at least be put on the CCR if not into
lazarus distribution itself.

> 2) THIS is the tricky one so I would like some advice on how I should do 
> it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed 
> events. Being a TCustomControl descendent, it doesn't have them - 
> TControl does - but it doesn't have a paint handler.
> Basically - there is no component that has a paint handler that also 
> handles key input.
> In the Delphi world people get around this by using callbacks and hooks.
> That's fine, if you are only on windows. Now sure, I could probably go 
> put in a bunch of IFDEF's and try to emulate them on each of the 
> widgetsets... but somehow I don't think that's the right way.
> The other way I can think of is to just code the keyboardEvents in, by 
> copying and pasting from one of the components that do have it - that 
> seems like clutter though - code duplication is never a good idea right.
> 
> So is there a third way I haven't thought of ? I am very open to 
> suggestions and I'm sure somebody here knows something I don't :)

I haven't looked into the sources deeply, but can't you override some
OnKeyXxx-methods to get the key events?

If not, maybe hooking into the surrounding forms events would suffice.

Marc


_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Graeme Geldenhuys]

On 30/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote:
>
> If one has last built project1, and then does some editing and just
> compiles (instead of building) project2, project2 may inherit units
> which where compiled with project1 conditionals, generating a mix-up,
> which may go undetected.
>
> That's why I was looking for a way to avoid this problem.

OK, I understand your issue now.  Simple solution is:  Always do a
Build All.  :-)

Create a keyboard shortcut for Build All, or use Ctrl+F9 for Build All
instead of the default compiler (I use Build = Ctrl+F9  and Build All
= Shift+Ctrl+F9).  Alternatively, install the Editor Toolbar package,
add all the different build and compile functions to the toolbar.  Now
everything is one click away!

Quick and easy solution... :-)


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Graeme Geldenhuys]

On 30/01/2008, Marco Alvarado <[EMAIL PROTECTED]> wrote:
> Isn't it lot easier to create an include file with all the defines,
> and include it everywhere you need it? If you need several sets of
> defines, just create higher level symbols that enable/disable those
> sets.

Thanks Marco.  We have done exactly that in the tiOPF project.  So far
it wasn't needed for fpGUI because I normally want to debug a certain
unit. One at a time, otherwise I get flooded with debug information.
Maybe I should incorporate the tiLog and tiGUILog unit from tiOPF into
fpGUI.  In the tiGUILog unit you can enable/disable debug information
at runtime. Very handy!!  The GUI log window get fed from a separate
log thread which uses caching and a lower priority so as not to slow
done the running of your application.


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Giuliano Colla]

Graeme Geldenhuys ha scritto:

On 29/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote:

So my question is still open. There's a way to make the IDE/compiler
aware of the change of conditionals? I'm the only one with this requirement?


I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
used to use application wide defines passing in -d.  This
caused lots of problems, like you described. I now instead use defines
per unit. Below the compiler mode (top of unit) I place a new line
{$Define DEBUG} to enable debuging per unit. If I want to disable such
debugging, comment that line as follows:  {.$Define DEBUG}

Obviously this works for me, because that's the only IFDEF's I have in
fpGUI.  Others usage may vary. My 2c worth.



Unluckily my mileage varies a lot. We have a codebase which is used to 
build different applications. Roughly 30 to 35 units and tens of 
thousands of lines.


When an application is reasonably different from others, it gets its own 
directory and all customization is made there.


But when some applications are very similar, and maybe go to the same 
customer, we may have two or three projects on the same directory, which 
are using the same source files, and a few conditionals scattered around 
to pick up the proper options where appropriate.


If one has last built project1, and then does some editing and just 
compiles (instead of building) project2, project2 may inherit units 
which where compiled with project1 conditionals, generating a mix-up, 
which may go undetected.


That's why I was looking for a way to avoid this problem.

Thanks, however,

Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

RE: [lazarus] Delphi 2006 and Lazarus

[Andrew Brunner]

I can't reproduce it.  But I do recall having not noticed a breakpoint
reached however the program wasn't visible.  I had to reset the debugger
during that session.

So if the two compilers share a DLL I can see how that would happen.  I'm
sure it wasn't intentional is opening them both up at the same time d/n pose
as a problem.

No big deal,

Andrew Brunner
Aurawin LLC

-Original Message-
From: Andrew Haines [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 29, 2008 8:59 AM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Delphi 2006 and Lazarus

Andrew Brunner wrote:
> The strangest thing just happened this morning.  I had Lazarus open and
> tried to open D2006.  Delphi threw a License file could not be found error
> and forced me into their registration screen.  No matter what I did I
> couldn't get in.  It wasn't until I closed Lazarus.exe down that I could
get
> in to Delphi.
> 
>  
> 
> Either Borland is looking for Lazarus or someone in Lazarus locked a file
> that Borland needed.  Which one is it?
> 

Well it's highly unlikely that Lazarus is trying to stop Delphi from
running.  See if you can reproduce your error and then rename
lazarus.exe to something else and see if it still happens.

Regards,

Andrew

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Leonardo M. Ramé]

It's my last post, "Powerful CGI applications".

http://leonardorame.blogspot.com

Graeme Geldenhuys escribió:

On 30/01/2008, "Leonardo M. Ramé" <[EMAIL PROTECTED]> wrote:

Lee, please read the last post in my blog (Powerful CGI applications).
It's an example on how to resolve that problem using PowUtils.


Where can I find your blog post? We have the same issue with db
connection pools.

Graeme.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives




_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Marco van de Voort]

On Wed, Jan 30, 2008 at 06:22:05PM +0100, Giuliano Colla wrote:
>> 
>> Yes. A Compile is a shortcut for a build. If you don't want the downsides,
>> do a build.
>> 
> 
> Out of sheer curiosity. Are you developing alone, or are you in charge of a 
> team, with a number of developers with various degree of skill and 
> experience, and responsible of the final quality?

I'm currently alone, but my previous jobs were teams (3-6 programmers)

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Graeme Geldenhuys]

On 30/01/2008, Lee Jenkins <[EMAIL PROTECTED]> wrote:
>
> I've used powtils a bit.  Fast, very fast.  The only thing I don't like is 
> with
> standard cgi you can't pool database connections, not sure about FastCGI 
> though


I second that. powutils work great.  We ported a GUI app to CGI and
could reuse a lot of code because everything is still written in
Object Pascal.  So far we are getting away with opening and closing
database connections the whole time, but I am sure if we start using
stress tests we would have to make a plan.  I heard Apache Modules
would be a possible solution to the database connection pool.

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Graeme Geldenhuys]

On 30/01/2008, Marius <[EMAIL PROTECTED]> wrote:
> Leonardo M. Ramé wrote:
>
> So if i understand correctly you add an layer around cgi. It looks
> pretty much like a service/deamon situation, everything will be
> forwarded to this deamon and that will generate the responses. Think
> this will work perfectly.

Umm, I was actually thinking the exact same thing a few months ago. I
haven't implemented anything yet, but thought it would work.  Nice to
know it does!  :-)

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [SPAM] Re: [lazarus] why do delphi users hate lazarus so much?

[Wanderlan Santos dos Anjos]

Vincent,

With this you got integrated debugger working at Win64 Lazarus?

-- 
Att,

Wanderlan Santos dos Anjos

On Jan 30, 2008 12:26 PM, Vincent Snijders <[EMAIL PROTECTED]> wrote:

> Joost van der Sluis schreef:
> >> Can you tell me more about the problems with GDB ?
>
>
> >  That it's not available at all at win64.
> > (since there's no gcc for win64)
> >
>
> That is not the case anymore. Try
>
> ftp://ftp.hu.freepascal.org/pub/lazarus/Lazarus-0.9.25-fpc-2.2.1-20080130-win64.exe
>
> Vincent
>
> _
> To unsubscribe: mail [EMAIL PROTECTED] with
>"unsubscribe" as the Subject
>   archives at http://www.lazarus.freepascal.org/mailarchives
>

Re: [lazarus] Cgi / PowUtils / FastCgi

[Graeme Geldenhuys]

On 30/01/2008, "Leonardo M. Ramé" <[EMAIL PROTECTED]> wrote:
> Lee, please read the last post in my blog (Powerful CGI applications).
> It's an example on how to resolve that problem using PowUtils.

Where can I find your blog post? We have the same issue with db
connection pools.

Graeme.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Marco Alvarado]

Isn't it lot easier to create an include file with all the defines,
and include it everywhere you need it? If you need several sets of
defines, just create higher level symbols that enable/disable those
sets.

Regards!
-Marco


2008/1/30, Graeme Geldenhuys <[EMAIL PROTECTED]>:
> On 29/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote:
> > So my question is still open. There's a way to make the IDE/compiler
> > aware of the change of conditionals? I'm the only one with this requirement?
>
> I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
> used to use application wide defines passing in -d.  This
> caused lots of problems, like you described. I now instead use defines
> per unit. Below the compiler mode (top of unit) I place a new line
> {$Define DEBUG} to enable debuging per unit. If I want to disable such
> debugging, comment that line as follows:  {.$Define DEBUG}
>
> Obviously this works for me, because that's the only IFDEF's I have in
> fpGUI.  Others usage may vary. My 2c worth.
>
>
> Regards,
>   - Graeme -
>
>
> ___
> fpGUI - a cross-platform Free Pascal GUI toolkit
> http://opensoft.homeip.net/fpgui/
>
> _
>  To unsubscribe: mail [EMAIL PROTECTED] with
> "unsubscribe" as the Subject
>archives at http://www.lazarus.freepascal.org/mailarchives
>

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Cesar Romero]

My personal taste is FastReport, and I think it is almost there to 
support FPC.


[]s


Cesar Romero

While you are all busy talking about reports.  Why don't each of you
fire off a email to the creators of ReportBuilder.  They have a
awesome reporting tool for Delphi. You could use it equally well from
code and designer plus it had a built-in script language. You could
report from datasets and pretty much any other type of data like
Objects etc...

I emailed them a few months back... They said they are keeping an eye
on Free Pascal and the Lazarus projects and would definately evalute
it if there was enough interest.

Regards,
  - Graeme -


On 30/01/2008, Andreas Berger <[EMAIL PROTECTED]> wrote:
  

Could I have some idea as to what you are using to generate reports? Do
you use internal report generators like :LazReport or external ones?
LazReport seems to be an incomplete implementation of FreeReport which
is also way outdated. Can some one please give me some hints.

Thanks,
Andreas



_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

  


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Vincent Snijders]

Graeme Geldenhuys schreef:

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:

You don't need ifdefs. You need to fix the differences.

Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled.

That is why there different widgetset backends too, not just to create different
widgets, but also to make them behave consistent.


But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.



Don't assume, research.

Not convinced,
Vincent.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

RE: [lazarus] Reports

[Sergio Samayoa]

> http://sourceforge.net/projects/braslib/

Latest release 0.4b in may 2006, CVS contents is 20 months old

> https://sourceforge.net/projects/reportlivre/

Latest release 0.1 in feb 2006, there's nothing in CVS

Better use LazReport which is the "de facto" reporting tool for lazarus.

Regards.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Graeme Geldenhuys]

On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:
>
> You don't need ifdefs. You need to fix the differences.
>
> Fix the gtk1 interface to scroll the memo.
> Fix the gtk1 interface to remove the scrollbars, when the memo is cleared
> Fix gtk1 and gtk2 interface to disable childforms, if the main form is 
> enabled.
>
> That is why there different widgetset backends too, not just to create 
> different
> widgets, but also to make them behave consistent.

But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I have a dream

[Graeme Geldenhuys]

On 29/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote:
> So my question is still open. There's a way to make the IDE/compiler
> aware of the change of conditionals? I'm the only one with this requirement?

I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
used to use application wide defines passing in -d.  This
caused lots of problems, like you described. I now instead use defines
per unit. Below the compiler mode (top of unit) I place a new line
{$Define DEBUG} to enable debuging per unit. If I want to disable such
debugging, comment that line as follows:  {.$Define DEBUG}

Obviously this works for me, because that's the only IFDEF's I have in
fpGUI.  Others usage may vary. My 2c worth.


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

[Mattias Gärtner]

Zitat von Andrey Gusev <[EMAIL PROTECTED]>:

> --- interfaces/win32/win32callback.inc (revision 13905)
> +++ interfaces/win32/win32callback.inc (working copy)
>  @@ -504,7 +504,7 @@
> if (ControlDC = 0) or not needParentPaint then
>  begin
>  DCIndex := Windows.SaveDC(PaintMsg.DC);
>  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
>  {$ifdef DEBUG_DOUBLEBUFFER}
>  Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
> with
> clipping rect (',
>
> I can provide application that's confirm my rightfulness.
> But i don't wish to do it, until all child-control negative effects will
> debugged (by me), it need to LazReport designer functionality.
> If wished, try to place oversized TPaintBox on TScrollBox and try it to
> scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Giuliano Colla]

Marco van de Voort ha scritto:

On Wed, Jan 30, 2008 at 01:56:40PM +0100, Giuliano Colla wrote:
with a program which compiles properly, but has a number of inconsistencies 
sometimes hard to detect.


Is there a way to overcome this problem?


Always do a build.


Am I the only one to see it as a problem?


Yes. A Compile is a shortcut for a build. If you don't want the downsides,
do a build.



Out of sheer curiosity. Are you developing alone, or are you in charge 
of a team, with a number of developers with various degree of skill and 
experience, and responsible of the final quality?


Giuliano


--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Graeme Geldenhuys]

While you are all busy talking about reports.  Why don't each of you
fire off a email to the creators of ReportBuilder.  They have a
awesome reporting tool for Delphi. You could use it equally well from
code and designer plus it had a built-in script language. You could
report from datasets and pretty much any other type of data like
Objects etc...

I emailed them a few months back... They said they are keeping an eye
on Free Pascal and the Lazarus projects and would definately evalute
it if there was enough interest.

Regards,
  - Graeme -


On 30/01/2008, Andreas Berger <[EMAIL PROTECTED]> wrote:
> Could I have some idea as to what you are using to generate reports? Do
> you use internal report generators like :LazReport or external ones?
> LazReport seems to be an incomplete implementation of FreeReport which
> is also way outdated. Can some one please give me some hints.
>
> Thanks,
> Andreas

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Giuliano Colla]

Mattias Gärtner ha scritto:

Zitat von Peter Vreman <[EMAIL PROTECTED]>:


Yesterday I posted a request for a way to improve ifdef handling, but
the discussion was led astray by my example, and turned into widgesets,
which was not the real issue.

So I repeat my request:

Sometimes ifdefs are unavoidable, as when they're used to turn on and
off customer options.

But IDE and fpc are unaware of conditional dependencies, so changing a
conditional doesn't force a recompile of some units as it would be

required.

Of course a Build All is the solution, but if one forgets, one may end
up with a program which compiles properly, but has a number of
inconsistencies sometimes hard to detect.

Is there a way to overcome this problem?
Am I the only one to see it as a problem?

I would gladly contribute an upgrade to implement this feature, but
advice from experts on where to start from, what to look at, if hooks
are already available in .lpi or in .ppu or .o files, etc. would be
highly appreciated.

It has been tried in the past. And it created very confusion situations so it
was disabled. There
are no plans to re-add this feature because it will cause more questions and
problem reports than
it solves.

And also how often is a define changed. In those couple of cases you can
simply press the Build
All or use the command line option -B.


Ok, then plan a. The IDE should add the -B automatically.



Thanks a lot.
Where should I start looking? Or it's the sort of things which is more 
readily done than explained?


Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Bogusław Brandys]

Christian U. wrote:

Andreas Berger schrieb:
Could I have some idea as to what you are using to generate reports? 
Do you use internal report generators like :LazReport or external 
ones? LazReport seems to be an incomplete implementation of FreeReport 
which is also way outdated. Can some one please give me some hints.

I use lazreport, it works good. Not perfect but ok.
Iam underway to add frChart wit TAChart again.
I think its an good start to make it more stable and add missing features.

best regards
Christian


I agree.This seems to be the best way.If we manage to add additional 
features to Lazreport like pascal script engine, chart, output to 
preview format then it become very powerful tool.


regards
Boguslaw

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Christian U.]

Andreas Berger schrieb:
Could I have some idea as to what you are using to generate reports? 
Do you use internal report generators like :LazReport or external 
ones? LazReport seems to be an incomplete implementation of FreeReport 
which is also way outdated. Can some one please give me some hints.

I use lazreport, it works good. Not perfect but ok.
Iam underway to add frChart wit TAChart again.
I think its an good start to make it more stable and add missing features.

best regards
Christian



Thanks,
Andreas

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives



_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Found serious bug in win32 interface #2

[Andrey Gusev]

--- interfaces/win32/win32callback.inc (revision 13905)
+++ interfaces/win32/win32callback.inc (working copy)
@@ -504,7 +504,7 @@
if (ControlDC = 0) or not needParentPaint then
begin
DCIndex := Windows.SaveDC(PaintMsg.DC);
- MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
+ MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
{$ifdef DEBUG_DOUBLEBUFFER}
Windows.GetClipBox(PaintMsg.DC, ClipBox);
DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
with
clipping rect (',

I can provide application that's confirm my rightfulness.
But i don't wish to do it, until all child-control negative effects will
debugged (by me), it need to LazReport designer functionality.
If wished, try to place oversized TPaintBox on TScrollBox and try it to
scroll (with above patch applied).

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[micahel schneider]

Am Mittwoch 30 Januar 2008 schrieb Andreas Berger:
> Could I have some idea as to what you are using to generate reports? Do
> you use internal report generators like :LazReport or external ones?
> LazReport seems to be an incomplete implementation of FreeReport which
> is also way outdated. Can some one please give me some hints.
>
> Thanks,
> Andreas

http://sourceforge.net/projects/braslib/
and
https://sourceforge.net/projects/reportlivre/

but i dont know if the devolopment is active or the projects are dead

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

[Andrey Gusev]

* Paul Ishenin <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
> That:
> --- interfaces/win32/win32callback.inc(revision 13905)
> +++ interfaces/win32/win32callback.inc(working copy)
> @@ -504,7 +504,7 @@
>   if (ControlDC = 0) or not needParentPaint then
>   begin
> DCIndex := Windows.SaveDC(PaintMsg.DC);
> -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
> {$ifdef DEBUG_DOUBLEBUFFER}
> Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

> clipping rect (',
>







I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked 
tabular-components on top of so fundamental bug ???


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

[Andrey Gusev]

* Paul Ishenin <[EMAIL PROTECTED]> [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
> That:
> --- interfaces/win32/win32callback.inc(revision 13905)
> +++ interfaces/win32/win32callback.inc(working copy)
> @@ -504,7 +504,7 @@
>   if (ControlDC = 0) or not needParentPaint then
>   begin
> DCIndex := Windows.SaveDC(PaintMsg.DC);
> -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
> +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
> {$ifdef DEBUG_DOUBLEBUFFER}
> Windows.GetClipBox(PaintMsg.DC, ClipBox);
> DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

> clipping rect (',
>





Please try to build ide with your changes and you'll see nice effects 

:)




I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked
tabular-components on top of so fundamental bug ???

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Leonardo M. Ramé]

If you have TeX/Latex installed you can create the Latex source file 
with your program, and let TeX process it, then show the resulting PDF 
or Postscript to the user.


Lee Jenkins escribió:

Andreas Berger wrote:
Could I have some idea as to what you are using to generate reports? 
Do you use internal report generators like :LazReport or external 
ones? LazReport seems to be an incomplete implementation of FreeReport 
which is also way outdated. Can some one please give me some hints.


Thanks,
Andreas



There is also PowerPDF, but I think this would be useful only through 
code as the designer seems built more for static pages.  But through 
code, seems to work like TCanvas from the little I've played with it.


I've been toying around with writing a simple report generator.

Report.AddDatasource(myObjectList);
Report.AddDetail;
Report.Detail.AddView('SalesTotal', otText, myObjectList, 'MyField');

I realize there is a lot involved with writing even a simple report 
engine, but I wonder if much of the work can be leveraged by just 
outputting to ODF format.




_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Reports

[Lee Jenkins]

Andreas Berger wrote:
Could I have some idea as to what you are using to generate reports? Do 
you use internal report generators like :LazReport or external ones? 
LazReport seems to be an incomplete implementation of FreeReport which 
is also way outdated. Can some one please give me some hints.


Thanks,
Andreas



There is also PowerPDF, but I think this would be useful only through code as 
the designer seems built more for static pages.  But through code, seems to work 
like TCanvas from the little I've played with it.


I've been toying around with writing a simple report generator.

Report.AddDatasource(myObjectList);
Report.AddDetail;
Report.Detail.AddView('SalesTotal', otText, myObjectList, 'MyField');

I realize there is a lot involved with writing even a simple report engine, but 
I wonder if much of the work can be leveraged by just outputting to ODF format.


--
Warm Regards,

Lee

"Everything I needed to learn in life, I learned selling encyclopedias door to 
door."


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [SPAM] Re: [lazarus] why do delphi users hate lazarus so much?

[Vincent Snijders]

Joost van der Sluis schreef:

Can you tell me more about the problems with GDB ?




 That it's not available at all at win64.
(since there's no gcc for win64)



That is not the case anymore. Try 
ftp://ftp.hu.freepascal.org/pub/lazarus/Lazarus-0.9.25-fpc-2.2.1-20080130-win64.exe


Vincent

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Wider use case for gamepack ?

[John Stoneham]

On Jan 30, 2008 9:05 AM, A.J. Venter <[EMAIL PROTECTED]> wrote:
> 2) THIS is the tricky one so I would like some advice on how I should do
> it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed
> events. Being a TCustomControl descendent, it doesn't have them -
> TControl does - but it doesn't have a paint handler.
> ...
> The other way I can think of is to just code the keyboardEvents in, by
> copying and pasting from one of the components that do have it - that
> seems like clutter though - code duplication is never a good idea right.

How about a middle ground: create a new TKeyboardEvents unit using
code from one of the components that already has it. Yes you will have
the initial code duplication in creating the unit in the first place,
but this would allow adding keyboard events to other controls simply
by inheriting from the base class. In fact, this may be something that
the LCL could use and incorporate itself in the future, if you get it
working property.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [SPAM] Re: [lazarus] why do delphi users hate lazarus so much?

[Joost van der Sluis]

Op dinsdag 29-01-2008 om 11:11 uur [tijdzone +0100], schreef willem:
> Joost van der Sluis wrote:
> >
> >>> Personally I would rank debugger way higher on my wishlist than packages.
> >>>   
> > That won't work. DDD is a frontend to GDB. And guess where the problem
> > is? The problem is GDB.
> >
> >   
> Can you tell me more about the problems with GDB ?

Well, what are you problems with the Lazarus debugger? Those are the
problems with GDB. (Almost)

Biggest problem is dat is doesn't support pascal-class-style properties,
that the DWARF support is limited. That it's not very stable/usefull in
Windows/Cygwin envirionments. That it's not available at all at win64.
(since there's no gcc for win64)

GDB's is most suitable to debug GNU/gcc applications on Unix systems.

Pascal and windows are supported, but very limited since most GDB
developers don't use those platforms and are not really interested in
them.

Joost

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Marius]

Mattias Gärtner wrote:

The package system of lazarus is different from Delphi. You don't need to
install a package to use it. 


Here i went wrong, i thought i always needed to install it into the IDE!

Thanks..

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Marco van de Voort]

On Wed, Jan 30, 2008 at 01:56:40PM +0100, Giuliano Colla wrote:
> with a program which compiles properly, but has a number of inconsistencies 
> sometimes hard to detect.
> 
> Is there a way to overcome this problem?

Always do a build.

> Am I the only one to see it as a problem?

Yes. A Compile is a shortcut for a build. If you don't want the downsides,
do a build.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Wider use case for gamepack ?

[A.J. Venter]

John Stoneham wrote:

On Jan 30, 2008 1:00 AM, A.J. Venter <[EMAIL PROTECTED]> wrote:

[...]
Anyway, I think I explained now what makes it special in depth. Either
the dev's will think it's cool, or they won't. I won't feel bad if they
don't - it's their prerogative, but at least let it be judged fairly.



Well, *I* think it's very cool. In fact, when I get back around to my
life-long pet project (a chess engine extraordinaire :) this will be
the first library I look at for the board UI.

Thanks, it's nice to have a vote of confidence- a chess board will not 
even need half the features :)


I finished the collisionDetection system today. Now only two things 
remain on my 1.0 TODO list.


1) The events from the colisionDetection, that's pretty easy, just set 
up some TNotifyEvents.
2) THIS is the tricky one so I would like some advice on how I should do 
it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed 
events. Being a TCustomControl descendent, it doesn't have them - 
TControl does - but it doesn't have a paint handler.
Basically - there is no component that has a paint handler that also 
handles key input.

In the Delphi world people get around this by using callbacks and hooks.
That's fine, if you are only on windows. Now sure, I could probably go 
put in a bunch of IFDEF's and try to emulate them on each of the 
widgetsets... but somehow I don't think that's the right way.
The other way I can think of is to just code the keyboardEvents in, by 
copying and pasting from one of the components that do have it - that 
seems like clutter though - code duplication is never a good idea right.


So is there a third way I haven't thought of ? I am very open to 
suggestions and I'm sure somebody here knows something I don't :)


Ciao
A.J.
--
"Any sufficiently advanced technology is indistinguishable from magic" - 
Clarke's law
"Any technology that is distinguishable from magic is insufficiently 
advanced" -Gehm's corollary
"Any technologist that is distinguishable from a magician is 
insufficiently advanced" - My corollary

The worlds worst webcomic: http://silentcoder.co.za/scartoonz
The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za

begin:vcard
fn:AJ Venter
n:Venter;AJ
org:Global Pact Trading Pty. Ltd.;OutKast Solutions
email;internet:[EMAIL PROTECTED]
title:Director of Product Development
tel;work:+27 21 554 5059
tel;fax:+27 11 252 9197
tel;cell:+27 83 455 9978
url:http://www.outkastsolutions.co.za
version:2.1
end:vcard

Re: [lazarus] Wider use case for gamepack ?

[John Stoneham]

On Jan 30, 2008 1:00 AM, A.J. Venter <[EMAIL PROTECTED]> wrote:
> [...]
> Anyway, I think I explained now what makes it special in depth. Either
> the dev's will think it's cool, or they won't. I won't feel bad if they
> don't - it's their prerogative, but at least let it be judged fairly.
>

Well, *I* think it's very cool. In fact, when I get back around to my
life-long pet project (a chess engine extraordinaire :) this will be
the first library I look at for the board UI.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Leonardo M. Ramé]

Sorry, its http://leonardorame.blogspot.com

Lee Jenkins escribió:

Leonardo M. Ramé wrote:
Lee, please read the last post in my blog (Powerful CGI applications). 
It's an example on how to resolve that problem using PowUtils.



Lee Jenkins escribió:

Marius wrote:

I've used powtils a bit.  Fast, very fast.  The only thing I don't 
like is with standard cgi you can't pool database connections...




Where is your blog?



_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Mattias Gärtner]

Zitat von Peter Vreman <[EMAIL PROTECTED]>:

> > Yesterday I posted a request for a way to improve ifdef handling, but
> > the discussion was led astray by my example, and turned into widgesets,
> > which was not the real issue.
> >
> > So I repeat my request:
> >
> > Sometimes ifdefs are unavoidable, as when they're used to turn on and
> > off customer options.
> >
> > But IDE and fpc are unaware of conditional dependencies, so changing a
> > conditional doesn't force a recompile of some units as it would be
> required.
> >
> > Of course a Build All is the solution, but if one forgets, one may end
> > up with a program which compiles properly, but has a number of
> > inconsistencies sometimes hard to detect.
> >
> > Is there a way to overcome this problem?
> > Am I the only one to see it as a problem?
> >
> > I would gladly contribute an upgrade to implement this feature, but
> > advice from experts on where to start from, what to look at, if hooks
> > are already available in .lpi or in .ppu or .o files, etc. would be
> > highly appreciated.
>
> It has been tried in the past. And it created very confusion situations so it
> was disabled. There
> are no plans to re-add this feature because it will cause more questions and
> problem reports than
> it solves.
>
> And also how often is a define changed. In those couple of cases you can
> simply press the Build
> All or use the command line option -B.

Ok, then plan a. The IDE should add the -B automatically.


Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Lee Jenkins]

Leonardo M. Ramé wrote:
Yes and no, the client forwards the request to the server, but inside 
the server you can use Powtils to process Html and other stuff.


The usage of this solution only applies to shared servers or situations 
where you can't use Apache modules, or install your own server.


Marius escribió:


But doesn't this defeat the purpose of powutils in this case? (the 
client is more or less reduced to a simple forwarder)




Pretty neat idea.  I was thinking of something along the same lines, but only as 
as data server.


client 
  |---> cgi/powtils <--> data server
  |
client 

The data server could maintain its own database connections/pooling etc.  There 
would be an overhead in passing the database back and forth, but...


--
Warm Regards,

Lee

"Everything I needed to learn in life, I learned selling encyclopedias door to 
door."


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Lee Jenkins]

Lee Jenkins wrote:

Leonardo M. Ramé wrote:
Lee, please read the last post in my blog (Powerful CGI applications). 
It's an example on how to resolve that problem using PowUtils.



Lee Jenkins escribió:

Marius wrote:

I've used powtils a bit.  Fast, very fast.  The only thing I don't 
like is with standard cgi you can't pool database connections...




Where is your blog?



Oh never mind, Leonardo.  I see another poster below provided a link...

--
Warm Regards,

Lee

"Everything I needed to learn in life, I learned selling encyclopedias door to 
door."


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Lee Jenkins]

Leonardo M. Ramé wrote:
Lee, please read the last post in my blog (Powerful CGI applications). 
It's an example on how to resolve that problem using PowUtils.



Lee Jenkins escribió:

Marius wrote:

I've used powtils a bit.  Fast, very fast.  The only thing I don't 
like is with standard cgi you can't pool database connections...




Where is your blog?

--
Warm Regards,

Lee

"Everything I needed to learn in life, I learned selling encyclopedias door to 
door."


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

RE: [lazarus] Reports

[Sergio Samayoa]

LazReport is based on FreeReport 2.32.

AFAIK there is no report component / engine for lazarus other than
LazReport.

You can try reportman (http://reportman.sourceforge.net) API in lazarus. Is
CLX based (Kylix) and only runs on Windows & Linux.

You could try http://www.openmfg.com/openrpt but I dont known if has an API
to use from other languages.

Regards.

-Mensaje original-
De: Andreas Berger [mailto:[EMAIL PROTECTED] 
Enviado el: Miércoles, 30 de Enero de 2008 04:39 a.m.
Para: lazarus@miraclec.com
Asunto: [lazarus] Reports

Could I have some idea as to what you are using to generate reports? Do 
you use internal report generators like :LazReport or external ones? 
LazReport seems to be an incomplete implementation of FreeReport which 
is also way outdated. Can some one please give me some hints.

Thanks,
Andreas

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Mattias Gärtner]

Zitat von Giuliano Colla <[EMAIL PROTECTED]>:

> Yesterday I posted a request for a way to improve ifdef handling, but
> the discussion was led astray by my example, and turned into widgesets,
> which was not the real issue.
>
> So I repeat my request:
>
> Sometimes ifdefs are unavoidable, as when they're used to turn on and
> off customer options.
>
> But IDE and fpc are unaware of conditional dependencies, so changing a
> conditional doesn't force a recompile of some units as it would be required.
>
> Of course a Build All is the solution, but if one forgets, one may end
> up with a program which compiles properly, but has a number of
> inconsistencies sometimes hard to detect.
>
> Is there a way to overcome this problem?
> Am I the only one to see it as a problem?
>
> I would gladly contribute an upgrade to implement this feature, but
> advice from experts on where to start from, what to look at, if hooks
> are already available in .lpi or in .ppu or .o files, etc. would be
> highly appreciated.

The codetools are already conditional aware. If a flag has changed units are
automatically reparsed.
The IDE saves the whole flags to the .compiled files and recompiles if something
changed. But it does not automatically pass the -B option.
The missing part is the compiler.
At the moment it only checks file dates and source checksums. Not the flags.

Solutions:
a) The IDE automatically passes the -B option if flags has changed. IMHO this is
a semigood solution, because it leads to too much rebuilds.
b) The compiler is enhanced to check for changed flags too. This has the
advantage that it can optimize the rebuild.


Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Vincent Snijders]

Marius schreef:

Vincent Snijders wrote:

Create a package for the units.


Should i create a (dummy) package to add search paths to lazarus???


No a real package to gather compiler options for a set of units.



Installing and recompiling the whole ide just to add a few paths sounds 
kind of stupid. (The tools do not contain any design stuff). Then again 
if this works it saves me a lot of typing


You don't need to rebuild the IDE, just create one package per directory and add the 
package to the project in the project inspector.


Vincent

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Mattias Gärtner]

Zitat von Marius <[EMAIL PROTECTED]>:

> Vincent Snijders wrote:
> > Create a package for the units.
>
> Should i create a (dummy) package to add search paths to lazarus???
>
> Installing and recompiling the whole ide just to add a few paths sounds
> kind of stupid. (The tools do not contain any design stuff). Then again
> if this works it saves me a lot of typing

The package system of lazarus is different from Delphi. You don't need to
install a package to use it. Just create a package, add your shared units to
the package and 'use' the package in every project, that should be able to use
your shared units.
Read here:
http://wiki.lazarus.freepascal.org/Lazarus_Packages
and here
http://wiki.lazarus.freepascal.org/Install_Packages

Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] I still have an ifdef request

[Peter Vreman]

> Yesterday I posted a request for a way to improve ifdef handling, but
> the discussion was led astray by my example, and turned into widgesets,
> which was not the real issue.
>
> So I repeat my request:
>
> Sometimes ifdefs are unavoidable, as when they're used to turn on and
> off customer options.
>
> But IDE and fpc are unaware of conditional dependencies, so changing a
> conditional doesn't force a recompile of some units as it would be required.
>
> Of course a Build All is the solution, but if one forgets, one may end
> up with a program which compiles properly, but has a number of
> inconsistencies sometimes hard to detect.
>
> Is there a way to overcome this problem?
> Am I the only one to see it as a problem?
>
> I would gladly contribute an upgrade to implement this feature, but
> advice from experts on where to start from, what to look at, if hooks
> are already available in .lpi or in .ppu or .o files, etc. would be
> highly appreciated.

It has been tried in the past. And it created very confusion situations so it 
was disabled. There
are no plans to re-add this feature because it will cause more questions and 
problem reports than
it solves.

And also how often is a define changed. In those couple of cases you can simply 
press the Build
All or use the command line option -B.

Peter


_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] I still have an ifdef request

[Giuliano Colla]

Yesterday I posted a request for a way to improve ifdef handling, but 
the discussion was led astray by my example, and turned into widgesets, 
which was not the real issue.


So I repeat my request:

Sometimes ifdefs are unavoidable, as when they're used to turn on and 
off customer options.


But IDE and fpc are unaware of conditional dependencies, so changing a 
conditional doesn't force a recompile of some units as it would be required.


Of course a Build All is the solution, but if one forgets, one may end 
up with a program which compiles properly, but has a number of 
inconsistencies sometimes hard to detect.


Is there a way to overcome this problem?
Am I the only one to see it as a problem?

I would gladly contribute an upgrade to implement this feature, but 
advice from experts on where to start from, what to look at, if hooks 
are already available in .lpi or in .ppu or .o files, etc. would be 
highly appreciated.


Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Marius]

Vincent Snijders wrote:

Create a package for the units.


Should i create a (dummy) package to add search paths to lazarus???

Installing and recompiling the whole ide just to add a few paths sounds 
kind of stupid. (The tools do not contain any design stuff). Then again 
if this works it saves me a lot of typing


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Vincent Snijders]

Marius schreef:
I need to add paths for indy and a few from lazarus\components for 
example which i mostly create at runtime, constantly changing the 
project compiler options ("other sources only used by IDE") is becoming 
boring.


Is there a place in lazarus to add search paths so lazarus can open 
3thparty units in the editor (much like the current search paths for the 
debugger). Or i'm i overlooking something obvious?


Create a package for the units.

Vincent

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Search paths

[Henry Vermaak]

On 30/01/2008, Marius <[EMAIL PROTECTED]> wrote:
> I need to add paths for indy and a few from lazarus\components for
> example which i mostly create at runtime, constantly changing the
> project compiler options ("other sources only used by IDE") is becoming
> boring.
>
> Is there a place in lazarus to add search paths so lazarus can open
> 3thparty units in the editor (much like the current search paths for the
> debugger). Or i'm i overlooking something obvious?
>

you can define it fpc.cfg (inside an ifdef)?

henry

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Search paths

[Marius]

I need to add paths for indy and a few from lazarus\components for 
example which i mostly create at runtime, constantly changing the 
project compiler options ("other sources only used by IDE") is becoming 
boring.


Is there a place in lazarus to add search paths so lazarus can open 
3thparty units in the editor (much like the current search paths for the 
debugger). Or i'm i overlooking something obvious?


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Leonardo M. Ramé]

Yes and no, the client forwards the request to the server, but inside 
the server you can use Powtils to process Html and other stuff.


The usage of this solution only applies to shared servers or situations 
where you can't use Apache modules, or install your own server.


Marius escribió:


But doesn't this defeat the purpose of powutils in this case? (the 
client is more or less reduced to a simple forwarder)


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Marius]

Leonardo M. Ramé wrote:
Lee, please read the last post in my blog (Powerful CGI applications). 
It's an example on how to resolve that problem using PowUtils.


This one i assume?
http://leonardorame.blogspot.com/2007/12/powerful-cgi-applications.html

So if i understand correctly you add an layer around cgi. It looks 
pretty much like a service/deamon situation, everything will be 
forwarded to this deamon and that will generate the responses. Think 
this will work perfectly.


But doesn't this defeat the purpose of powutils in this case? (the 
client is more or less reduced to a simple forwarder)


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Marius]

Bee wrote:
Yup. But FPC also has its own CGI framework. It might be a good 
alternative besides Powtils. I never use it though.


Pretty and simple as far i can see with the tcgiapplication. The lcl cgi 
package addon is not really helpfull (i have some problems with the 
tdatamodule properties which disappear each time).


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Marius]

Lee Jenkins wrote:
I've used powtils a bit.  Fast, very fast.  


Yeah it is. However it looks like theres little classes and structure, 
but thats just the impression i got after a few hours in comparison to a 
standard cgi application.


The only thing I don't like 
is with standard cgi you can't pool database connections, not sure about 
FastCGI though which I read was supposed to be opened only once and 
reused which I have not tried with powtils yet.


I know MS just introduced a fastcgi layer on IIS, and i like the fastcgi 
ideas, but the classes i have seen in the fpcsrc\utils\fppkg\lnet dir 
are quite complicated. Caching opf-objects and connections would however 
be very usefull as i need to setup connections to 2 or 3 db's.


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Workarea thing on Mac OS X

[EarMaster - Bent Normann Olsen]

Hey all,

I'm new to this list, so this question might be misplaced or already been
answered.

Workarea on Lazarus isn't implemented, I believe because of the different
ways of handling these things on different systems.

How do one read different screen settings on a Mac OS X with Lazarus? Like
WorkareaHeight in Delphi?

Thanks in advance,
Normann

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Cgi / PowUtils / FastCgi

[Leonardo M. Ramé]

Lee, please read the last post in my blog (Powerful CGI applications). 
It's an example on how to resolve that problem using PowUtils.



Lee Jenkins escribió:

Marius wrote:

I've used powtils a bit.  Fast, very fast.  The only thing I don't like 
is with standard cgi you can't pool database connections...


_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Reports

[Andreas Berger]

Could I have some idea as to what you are using to generate reports? Do 
you use internal report generators like :LazReport or external ones? 
LazReport seems to be an incomplete implementation of FreeReport which 
is also way outdated. Can some one please give me some hints.


Thanks,
Andreas

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] DropFiles Implementation

[Paul Ishenin]

Tom Gregorovic пишет:

Then there will be problem, how to track this feature inside some
custom controls. Assigning to a published event is not a clear
solution. Maybe instead of property there can be some protected
function like SetAllowDropFiles for these cases.

But I think the others want to handle it via OnDragDrop and then you
need some enable flag.



I think that TWinControl.AllowDropFiles (TWinControl.AllowOSDrop ?) can 
be added.


Best regards,
Paul Ishenin.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] DropFiles Implementation

[Tom Gregorovic]

On Jan 29, 2008 8:25 PM, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
> Did OnDropFiles make it to 0.9.24? If so, any radical change can
> potentially cause a lot of headache for people already using it.
>
> On Jan 29, 2008 3:46 PM, Tom Gregorovic <[EMAIL PROTECTED]> wrote:
> > - there must be some property to enable accepting files, like does
> > AllowDropFiles now
>
> Maybe it could be simply defined as OnDropFiles <> nil so no new
> property is needed. We can hook when OnDropFiles is set and call an
> widgetset function to warn the widgetset it is being (de)activeated.
> Do you think this would work on windows?
>

Then there will be problem, how to track this feature inside some
custom controls. Assigning to a published event is not a clear
solution. Maybe instead of property there can be some protected
function like SetAllowDropFiles for these cases.

But I think the others want to handle it via OnDragDrop and then you
need some enable flag.

Tom

_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] IDE freezes with 2 status bars

[Dave Parsons]

On Wed, 30 Jan 2008 09:26:03 +0100, Vincent Snijders wrote:

> Dave Parsons schreef:

> > 
> > Still present in 0.9.25 from svn of a couple of weeks ago.
> 
> Not present anymore since 2008-01-22 07:06,  revision 13826

Good to hear it, thanks.

Dave


_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] IDE freezes with 2 status bars

[Vincent Snijders]

Dave Parsons schreef:

Hi,

I've just discovered a regression when porting an app back
to Win32 from Linux which is a show stopper for us.

The IDE freezes with 2 status bars using 0.9.24 on WinXP

to reproduce:-
start Lazarus with a new project.

1. drop a status bar on the form - IDE still responsive
2. drop another status bar on the same form - IDE freezes solid.
The only way out is to kill Lazarus with the task manager.

Still present in 0.9.25 from svn of a couple of weeks ago.


Not present anymore since 2008-01-22 07:06,  revision 13826

Vincent

P.S. Please remove the reply to header.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] IDE freezes with 2 status bars

[Dave Parsons]

Hi,

I've just discovered a regression when porting an app back
to Win32 from Linux which is a show stopper for us.

The IDE freezes with 2 status bars using 0.9.24 on WinXP

to reproduce:-
start Lazarus with a new project.

1. drop a status bar on the form - IDE still responsive
2. drop another status bar on the same form - IDE freezes solid.
The only way out is to kill Lazarus with the task manager.

Still present in 0.9.25 from svn of a couple of weeks ago.
Works ok with 0.9.20 on Linux & IIRC with 0.9.20 on Win32.

Cheers,
Dave



_
 To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives