Re: [lazarus] TRunInThread - Progress, but new problem
On Sunday 05 March 2006 08:43, A.J. Venter wrote: > Well since my last mail on this a few weeks ago, I have made quite a bit of > progress in my attempts to create a component that will allow me to call a > tprocess in a thread while retrieving the output "live". > > The structure I have no compiles, and can be placed on a form - it is all > but right. The only trouble is - when I call the run method, it throws an > access violation, the stack trace places it at line 76 (the line where I > call FProcessThread.resume), I did a check and the first line of the > execute method does not ever get executed. > Mmmm, I think I know now why this is happening, though now I have even LESS of an idea how to prevent it. I instantiated TProcessThread directly in a test program (obviously this left me with no events or such but I was just trying to see if it worked) when I call TProcessThread.Create the program dies with error 232 complaining that there isn't a thread driver. I checked the lpr, it calls cthreads. I checked lazarus.pp - that too calls cthreads, the only thing I can imagine is that I must somehow call cthreads in olpack, putting it in olpack.lpk doesn't work - lazarus recreates the file on compile/save apparently, putting it in runinthread.pas doesn't work (probably because it's not early enough in the uses clause) - leaving me unable to determine where I SHOULD add it - or is this the IDE telling me that what I am trying to do is simply not possible ? TIA A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
> Maybe a StringBuffer type is needed for pascal Do you mean "in pascal" or "for FreePascal"? ;-) > for very large strings that > constantly change via concatenations. Instead of reserving memory for the > ansistring to whatever amount you request, the stringbuffer type would reserve > extra memory for you in a specifyable increment (256K, 128K, 20K, whatever you > choose). If the string has a concatenation on queue which is larger than the > increment size, then the stringbuffer allocates enough memory with overlap > (several increments until it fills the need). I guess it's not so hugely useful or else someone would have contributed it already. This is much more important in Java because the String objects are constant/immutable and thus can't be reallocated. But maybe a method in TStringList to return all the text without adding linefeeds could be handy ;-) Cheers, Flávio _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] TRunInThread - Progress, but new problem
Well since my last mail on this a few weeks ago, I have made quite a bit of
progress in my attempts to create a component that will allow me to call a
tprocess in a thread while retrieving the output "live".
The structure I have no compiles, and can be placed on a form - it is all but
right. The only trouble is - when I call the run method, it throws an access
violation, the stack trace places it at line 76 (the line where I call
FProcessThread.resume), I did a check and the first line of the execute
method does not ever get executed.
At this stage the whole thing consists of two units.
processthread.pas implements the TprocessThread class which is just a simple
TThread descendent which runs a command.
TRunInThread is a TComponent descendent which encapsulates TProcessThread with
a component, setting up an instantiation of it, executing it, storing and
updating the output etc.
In theory it should all work so I really do not know why it's throwing a
trace, perhaps somebody else can tell me what to change ?
I attach both the units for your viewing pleasure.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
unit processthread;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils,process;
Type
TProcessThread = class(tthread)
protected
procedure Execute; override;
public
fcommand : String;
Constructor Create(isSuspended : boolean);
end;
Var
MemStream :TMemoryStream;
Running:Boolean;
implementation
constructor TProcessThread.Create(isSuspended : boolean);
begin
MemStream := TMemoryStream.Create;
inherited Create(isSuspended);
end;
procedure TProcessThread.Execute;
const
READ_BYTES = 2048;
Var
Process :Tprocess;
n: LongInt;
BytesRead: LongInt;
begin
Process := TProcess.create(nil);;
Process.CommandLine := Fcommand;
Running := True;
{Actually run the thing and catch the output}
BytesRead := 0;
Process.Options := [poUsePipes,poNoConsole];
Process.Execute;
while Process.Running do
begin
// make sure we have room
MemStream.SetSize(BytesRead + READ_BYTES);
// try reading it
n := Process.Output.Read((MemStream.Memory + BytesRead)^, READ_BYTES);
if n > 0
then begin
Inc(BytesRead, n);
end
else begin
// no data, wait 100 ms
Sleep(100);
end;
end;
// read last part
repeat
// make sure we have room
MemStream.SetSize(BytesRead + READ_BYTES);
// try reading it
n := Process.Output.Read((MemStream.Memory + BytesRead)^, READ_BYTES);
if n > 0
then begin
Inc(BytesRead, n);
end;
until n <= 0;
MemStream.SetSize(BytesRead);
Process.Free;
Running := False;
end;
end.
unit RunInThread;
{$mode objfpc}{$H+}
interface
uses
LResources,Classes, SysUtils,ProcessThread;
Type
TNewOutPutEvent = procedure(Sender: TObject;NewOutPut:TStringList) of object;
TRunInThread = Class(TComponent)
private
FOutPut : TStringList;
FNewOutPut :TStringlist;
FProcessThread : TProcessThread;
FCommand : String;
FRunning : Boolean;
FOnNewOuput : TNewOutPutEvent;
FOnDone : TNotifyEvent;
FLastSize : Integer;
FLastMSize : Integer;
procedure GetOutPut;
destructor destroy; override;
public
constructor Create(AOwner: TComponent);
procedure run;
published
property Command : String read FCommand write Fcommand;
property OutPut: TStringLIst read FOutput;
property Running: Boolean read FRunning;
property OnNewOutput : TNewOutPutEvent read FOnNewOuput write FOnNewOuput;
property OnDone : TNotifyEvent read FOnDone Write FOnDone;
end;
procedure Register;
implementation
procedure Register;
begin
RegisterComponents('OLPack',[TRunInThread]);
end;
Constructor TRunInThread.Create(AOwner: TComponent);
Begin
FLastSize := 0;
FLastMSize := 0;
FOutPut := TStringList.Create;
FNewOutPut := TStringList.Create;
FProcessThread := TProcessThread.Create(false);
FProcessThread.FCommand := FCommand;
if Assigned(FProcessThread.FatalException) then
raise FProcessThread.FatalException;
inherited create(AOwner);
end;
Destructor TRunInThread.Destroy;
Begin
FProcessThread.Suspend;
FOutPut.Free;
FNewOutPut.Free;
FProcessThread.Terminate;
inherited destroy;
end;
Procedure TRunInThread.GetOutPut;
Begin
FOutPut.LoadFromStream(MemStream);
end;
procedure TRunInThread.Run;
Var I : Integer;
Begin
FProcessThread.Resume;
FRunning := True;
While Running do
Begin
If MemStream.Size <> FLastMSize then
begin
FLastMSize := MemStream.Size;
GetOutPut;
[lazarus] button icons for lazarus
After some positive feedback on the suggestion last week, I did the work and created a full set of button icons for lazarus. This set provides a replacement for everything in the standard delphi "buttons" directory under images. Right now, only xpm's exist. Most of the icons were taken from the Nuvola set for KDE (lgpl license) but a few came from CrystalSVG as well. Where I could not find a suitable replacement, I made it myself. Overall they are as consistent as I could get them and should hopefully help give lazarus apps a more consistent look and feel. Most importantly though I hope they will save lazarus programmers some time by providing prebuilt icons for most common button-tasks so that nobody has to sit and create/find icons first. The icon names were taken directly from their delphi counterparts for familiarity reasons (of course it also made it a lot easier for me to see what I had done yet and what was waiting). Andrew Higgs has offered to do ico format versions of them, I personally see no point in redoing the masked bitmap format that delphi used though I am open to the idea if somebody can give a good reason and will volunteer for the labour. However, I do think that before Andrew starts to do ico's I would like everyone interested to take a look at the icons and make suggestions for improvements, if you send me a better version of one of them, I will happily replace it. The bit which would make me very happy if guys on top were so inclined would be to see it included in the main lazarus tree eventually (based on it's delphi counterpart it should go under $LAZARUSDIR/images/buttons) but that should wait until after people had a chance to at least comment on the current set. I am wearing my asbestos undies so if you think I did a horrible job, you are welcome to tell me :) The icons are in my subversion server and can be checked out with: svn co svn://silentcoder.co.za/lazarus/buttons/ Ciao A.J. PS. Andrew, mail me with the username and password you would like, and I will give you write access to the tree. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
- Original Message - From: "Markku Niskanen" <[EMAIL PROTECTED]> To: Sent: Saturday, March 04, 2006 4:20 PM Subject: Re: [lazarus] Object pascal a "Modern Language" > On Sat, 4 Mar 2006 08:41:53 -0800, Dale Welch <[EMAIL PROTECTED]> wrote: > > >But everyone always knew java was slow. It wasn't meant > >to be able to be your primary language for large projects. > > This is where I have do disagree, having used Java. Example: I wrote > a piece of linguistic software in Java. It needed an lot of HEAVY string > handling. Using the wrong technique in concatenation (Strings instead of > StringBuffer) I would have had problems. Using the language in a correct > manner (Strings where necessary and StrinbBuffer in everywhere else) I > got all the functionality I needed and the performance was excellent. Using > just Strings is one of the common mistakes that causes low performance > when lots of concatenations are done as every concatenation creates a > new object. Maybe a StringBuffer type is needed for pascal for very large strings that constantly change via concatenations. Instead of reserving memory for the ansistring to whatever amount you request, the stringbuffer type would reserve extra memory for you in a specifyable increment (256K, 128K, 20K, whatever you choose). If the string has a concatenation on queue which is larger than the increment size, then the stringbuffer allocates enough memory with overlap (several increments until it fills the need). _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] ipHTMLPanel Selection paint
- Original Message -
From: "Panagiotis Sidiropoulos" <[EMAIL PROTECTED]>
To:
Sent: Saturday, March 04, 2006 9:41 AM
Subject: [lazarus] ipHTMLPanel Selection paint
> On Windows version of Lazarus I added a small part of code in order to
> paint selected part of page viewed. it seem it is never called. This
> same addition to Linux version of Lazarus does not afect selection is
> painted.
>
> Addition made in ipHTML unit about line 8040.
>
> {$IFDEF IP_LAZARUS}
> file://DebugLn('TIpHtml.PaintSelection PatBlt not implemented');
> BitMapToInvert := TBitMap.Create;
> BitMapToInvert.Width := R.Right - R.Left;
> BitMapToInvert.Height := R.Bottom - R.Top;
> BitMapToInvert.Canvas.CopyMode := cmMergePaint;
> BitMapToInvert.Canvas.CopyRect( Rect( 0, 0, BitMapToInvert.Width,
> BitMapToInvert.Height ), PaintBuffer, R );
> PaintBuffer.CopyRect( R, BitMapToInvert.Canvas, Rect( 0, 0,
> BitMapToInvert.Width, BitMapToInvert.Height ) );
> BitMapToInvert.Free;
> {$ELSE}
> PatBlt(PaintBuffer.Handle, R.Left, R.Top, R.Right - R.Left, R.Bottom -
> R.Top, DSTINVERT);
> {$ENDIF}
>
> By default ipHTMLPanel paints selected region (white chars on black
> background), but SelectAll methos oes not paint. Project is compiled for
> gtk2.
>
> Panagiotis
>
This section of code it's not called anymore since selection is now painted at
the same time content is rendered, if selectAll do not work it's a bug. Please
submit a bug report.
Jesus Reyes A.
__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
On Sat, 4 Mar 2006 08:41:53 -0800, Dale Welch <[EMAIL PROTECTED]> wrote: >But everyone always knew java was slow. It wasn't meant >to be able to be your primary language for large projects. This is where I have do disagree, having used Java. Example: I wrote a piece of linguistic software in Java. It needed an lot of HEAVY string handling. Using the wrong technique in concatenation (Strings instead of StringBuffer) I would have had problems. Using the language in a correct manner (Strings where necessary and StrinbBuffer in everywhere else) I got all the functionality I needed and the performance was excellent. Using just Strings is one of the common mistakes that causes low performance when lots of concatenations are done as every concatenation creates a new object. I want to point out that I also wrote a very exotic Replace function in plain Java that I thought would NEVER be fast enough, knowing that I am dealing with bytecode. To my surprise the code was faster than I could ever have dreamed and could be run just like any native .exe. Three years later I wrote the same routines in PHP and used every possible piece of optimization I could think of (and I know PHP very well). I ended up with junk that used 40x CPU compared with the Java one. And believe me, I did everything I could think of. Nope, the PHP can only be used if I write the critical parts (~50% of the application code in C as a PHP extension. So there is a difference between a bytecode/JIT-compiled and a sort-of-compiled language. After that I thought of rewriting the same app in FPC but have not yet had the time to start the project. What I noticed, however, was that a lot of work should be done to achieve the same functionality the Java String/Stringbuffer/Tokenizer classes have - we do not have them in plain FPC. What I really miss is in FPC the multitude of good classes, good functions that Java has. Tokenizer is a good example of a effort-saving utility class that is very well written in Java. Java is definitely NOT slow if written properly and used properly. At least Java basic things (String handling, hash maps, loops etc) perform very well compared with just about any language. With lots mathematics, matrixes and things like that I know less about things may be different though. As for large projects anybody can have a look at Eclipse. In my latest project it was chosen as the default environment and we never had any performance problems with it... not to mention big sites with JSPs and servlets and the J2EE abstraction level. Markku -- [EMAIL PROTECTED] _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
Well, a theme bug... guess the theme author must go hide really well now :) And usually then it isn't a TGroupBox any more but a TAlertableFrame that is derived from TGroupBox and has some extra style properties like "overloaded-reactor-color" ... :) I feel like I'm still missing your point :( Why You want all world move to theme. I know : theme are are good and we can do everything with it. But its only feature (its good ) not obligation Lazarus was made with one aspect: compatibility with Delphi and till now it has no "theme thinking" at API layer. Of course we can all stuff prepare to theme, but many of us have hundred thousand lines of code without theme, and now we all must move all code to theme: what for? for new bugs, not necessary feature? Not all people need theme, only working software. If they don't like programs they change it. You can't tell: don't use Color only theme. Programmer have to know what is better, he (not ) decided, if he goes wrong, he will not sell program. And when we talk about freedom: this is freedom to make mistake or not, Lazarus should (it can be) work with and without theme, even it (programing without theme) is bad When I say : live its not so simple, I think: nobody know all aspect and environment of every program. One tools never be enough good to use in any case. Darek _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
Vincent Snijders wrote: Yury Sidorov wrote: I think lazarus support is fine. I will test later tonight (no time now). Setting up the build environment takes longer than expected. I think most things can be done by carefully setting up the environment (fpc.cfg and directory layout). Maybe some things in the IDE can be made more comfortable, but using fpc (and not ppcXXX) as compiler and passing the -P compiler option, every thing should work. I will be trying myself, just to be sure, but this takes some time. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Help Authoring questions
Hello all, Being a total noob when it comes to the subject of Help Authoring, I would like to ask people for pointers and suggestions on writing end user Help Documentation, possibly context sensitive, for a Lazarus app. What is involved implementing context sensitive help in Lazarus ? I can see the Object Inspector has help related properties, but obviously there is more to it than that. I don't see anything on the subject on the Wiki. Looking at fpdoc and Lazde, it appears to me they are mostly geared towards documenting source code. Looking at what's available in terms of standalone help authoring editors, it looks like most of what's out there seems to be Windows centered, and I am concerned about multi-platform usage. Any suggestions on what editor to use ? Any comments welcome. Thankyou, George _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Grids fixes
--- Colin Western <[EMAIL PROTECTED]> escribió:
> The attached fixes two problems I noticed that were exposed with a
> small
> display area for a grid:
>
> 1. A range check error if compiled with checks on
I couldn't reproduce this problem (in linux) how can I do
to reproduce?
if aPage<0 then
aPage:=0;
ScrollInfo.nPage := APage;
would help?
> @@ -2162,7 +2162,8 @@
> {$endif}
> ScrollInfo.nMin := 0;
> ScrollInfo.nMax := ARange;
> -ScrollInfo.nPage := APage;
> +if aPage > 0 then
> + ScrollInfo.nPage := APage;
> SetScrollInfo(Handle, Which, ScrollInfo, True);
>end;
> end;
Jesus Reyes A.
___
Do You Yahoo!?
La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Grids fixes
--- Colin Western <[EMAIL PROTECTED]> escribió:
> The attached fixes two problems I noticed that were exposed with a
> small
> display area for a grid:
>
> 1. A range check error if compiled with checks on
> @@ -2162,7 +2162,8 @@
> {$endif}
> ScrollInfo.nMin := 0;
> ScrollInfo.nMax := ARange;
> -ScrollInfo.nPage := APage;
> +if aPage > 0 then
> + ScrollInfo.nPage := APage;
> SetScrollInfo(Handle, Which, ScrollInfo, True);
>end;
> end;
Would:
if Apage<0 then
___
Do You Yahoo!?
La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
Hi, Am Samstag, den 04.03.2006, 20:58 +0200 schrieb A.J. Venter: > > > The default should always be to follow the theme, the programmer should > > > think five or six times before overriding it - but when he does, it must > > > be assumed that he had a good reason and his changes should be honoured. > > > > Exactly. > > > Let me try to explain what I mean with an EXTREME example. > Say you are coding the control system for a nuclear power station. Now 99% of > your screen is showing the current values for things and with some sliders > the operators can adjust some of the equipment settings to ensure that > everything remains normal. > > For almost all times this is ALL there is to it. But there on one side is a > few critical values, these ones won't just be changed by adjusting one thing, > if they are outside tolerance values then that means a trained expert will > need to adjust probably 80% of those sliders to very specific settings to > deal with what is in fact an emergency. > > So when one of those goes out of tolerable range you start by activating > every > alarm in the building, syrens howling, strobe lights flashing the works. But > on screen you do NOT want everything highlighted. What you DO want is for the > area around the specific value that triggered the problem to start cycling > through red-green-blue-orange-purple and some more colours at a fairly high > rate so the operator your alarm woke up will INSTANTLY see which value is out > of range and can start fixing it immediately. > You don't want to pop up a dialog - clicking ok means it takes longer before > he starts adjusting the parameters, but you MUST highlight THAT specific > element in a way that should NEVER happen otherwise. > > The element may be a TEdit on a tgroupbox. Now if an emergency exists and you > start colour-flashing the tgroupbox to draw attention to the RIGHT tedit but > a theme overrides your colour calls so it doesn't flash and the whole town is Well, a theme bug... guess the theme author must go hide really well now :) And usually then it isn't a TGroupBox any more but a TAlertableFrame that is derived from TGroupBox and has some extra style properties like "overloaded-reactor-color" ... :) I feel like I'm still missing your point :( > flattened before the operator finds the right value (he cannot fix the > problem until he knows WHAT the problem is) - well the whole theory just went > up in smoke (as did the town). > > In a non computerized nuclear power station, a big LED would have flashed > below the dial with the out of sync value, in a computerized version you HAVE > to find a way of getting exactly the same kind of notification and theme must > not prevent you from doing it, especially since computerising has so many > other usefull advantages (a computer could solve simpler cases itself, like > automatically increasing cooling if the temperature rises by a few degrees) > in other words, a computerized interface is a good idea - but it MUST be able > to override the theme when needed. > > Yes this is probably the most extreme example there is but it is a very real > one, and just because most of us are not coding nuclear reactor controls > doesn't mean that our reasons for occasionally having to FORCE colors or > fonts are not good ones. Yes, occassionaly being the keyword :) I am in favour of bondage & discipline, so I want the case of force-setting colors to be hard and weary and the case of installing a normal style property to be easy :) That is not to say that it should be impossible to set your own colors, just really really hard. That's also why it's so hard to do in gtk+. And it should be kept that hard to do (at least). Of course that is all theoretical talk because when one of the supported widgetsets of the LCL doesn't support themes, we are screwed and _have to_ expose Color & Font directly... we'll see.. cheers, Danny _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
Hi, Am Samstag, den 04.03.2006, 19:44 +0200 schrieb A.J. Venter: > > less power. It's always like that. The language of a human (and maths) > > is just so much more advanced than any computer language, it depresses > > me at times. (Assembly language is so primitive that we all stopped > > talking it by now, except when we absolutely must do it. But it sure is > > "flexible", like an atom - you can use tons of them to build a copy of > > the earth, given you have a few billion years time and way too much > > patience for your own good :)) > > > This is a nice argument but it's highly subjective, I find OP to be the > computer language CLOSEST to human language, Exactly. I count Object Pascal to the best there are (speaking about expressiveness / clarity), actually (along with ada, oberon, smalltalk). > python and java both inherrited > too much ascii art from C++ java did, python not really.. most is pretty verbose and nice there... have an example? > and don't get me STARTED on perl ! eeek. well we all know the-language-we-dont-mention that is write-only, bogged down with as many operators as there a special characters on the keyboard and that has "evolved" to a real complex incomprehensible monster. > > One of the things I love about OP (a compiled language) is that it uses > mostly > WORDS to say things, not symbols, true it's slightly more typing - but it is > so much more readable. yes, especially for rare stuff. I mean "+" for "addition" is okay, but what's up with "&&" instead of "and", I mean it saves one char, but needs you to use the shift key now, so it saves 0 keys. And its cryptic. What is that for? And if you absolutely must, use "^" damnit, like in maths. Don't invent _another_ set of symbols for the same thing. And if the exact symbols don't exist on the keyboard, that should tell you something... like "hey! those symbols are not used by anyone on a computer" :) > > I always tell my trainee's "If I NEED comments to read your code - it is > badly > written". Of course I also make it absolutely clear that any program of more > than 100 lines which doesn't have comments is pretty much guaranteed to > ensure they won't get a permanent position with me, but comments should be > there to add clarity NOT to tell you what the code DOES ! yes. But I am at a phase now where even seeing "design patterns" strike me as odd. The language should do them if they are so essential. Why can I see them (and not really well either) in the source code? like observer pattern. That should be a property-change-notify instead... and so on... as a side note: what the hell is will all the people removing enumerations (ex. "TDirection = (East, South, West, North)") in later languages? If I can't write a lexer in a language something has to be really f*cked up with it. What are they thinking? (I'd really be interested, strikes me as odd...) > That should be > obvious just from reading the code. > > This isn't possible in most languages, in OP it's the default - that is why I > think it's such a brilliantly designed language, and the fact is this is > something Pascal has boasted since Wirth invented the first version of it. > > Pascal is probably the only language you can read (large sections of) aloud > without stuttering. yes > In other words, by your argument those languages have all > failed at exactly the supposed REASON they are interpreted/bytecompiled in > the first place. Mostly, yes. But it's also because the marketdroids only like stuff that builds on "proven" stuff, which of course means lowest-common-denominator, e.g. assembly or C. Changing slowly nowadays, though. For the wrong reasons. But I don't care about the reasons as long as the result is good in the end :) > > Like I said, it's way too subjective an argument. Now don't get me wrong, I > actually rather like python, it has a nice design (although the whole > whitespace has meaning thing annoys me a bit) and a fairly decent syntax but > the simple reality is that I write code which will end up running on thin > clients - that means if a computer slows down to any noticeable degree when > running 50 copies of the program at once -it's not good enough, and that > rules out python for anything complex. Yes, it should be compiled and type checking instead. Check out http://boo.codehaus.org/ though. I am generally opposed to scripting languages, *but* even for compiled languages garbage collection is the way to go, after having 40 years to test it, I think by now we can get it right :) (This is one of the major points object pascal doesn't have... it's not surprising and it's not essential and there are reasons against it, but manual memory management is just... so.. sigh... so manual; although "interface" refcounting is nice too - slower though) > Lazarus works beautifully, I have the language that I like for most work, I > can quickly design my GUI's in a RAD environment and the programs run FA
[lazarus] Menu fix
Under gtk1 on linux it is not possible to have an underscore character
displayed. The attached patch fixes this
Colin
diff -uNr lazarus/lcl/interfaces/gtk/gtkproc.inc /dos/fpc/lazarus.w/lcl/interfaces/gtk/gtkproc.inc
--- lazarus/lcl/interfaces/gtk/gtkproc.inc 2006-03-04 11:04:49.0 +
+++ /dos/fpc/lazarus.w/lcl/interfaces/gtk/gtkproc.inc 2006-03-04 11:29:14.0 +
@@ -5663,15 +5681,21 @@
// It would be cool, to know if a window manager with the gnome feature
// is running, but there is probably no reliable code to do that, so we
// simply delete all ampersands and don't set the letter shortcut.
-DeleteAmpersands(s);
+// DeleteAmpersands(s);
+// gtk_label_set_text(LabelWidget,PChar(s));
+
+// Do not use gtk_label_parse_uline as it mangles underscore characters
+System.Delete(s,ShortCutPos,1);
gtk_label_set_text(LabelWidget,PChar(s));
-Accelerate(LCLMenuItem,MenuItemWidget,
- gtk_label_parse_uline(LabelWidget,PChar(s)),
- 0,{$Ifdef GTK2}'activate'{$Else}'activate_item'{$EndIF});
+gtk_label_set_pattern(LabelWidget, PChar(StringOfChar(' ', ShortCutPos-1)+'_'));
+//Accelerate(LCLMenuItem,MenuItemWidget,
+ //gtk_label_parse_uline(LabelWidget,PChar(s)),
+ //0,{$Ifdef GTK2}'activate'{$Else}'activate_item'{$EndIF});
end;
end
else begin
gtk_label_set_text(LabelWidget,PChar(s));
+ gtk_label_set_pattern(LabelWidget, nil); // Ensure any underlines removed
end;
end;
Re: [lazarus] setColor part 3
> > The default should always be to follow the theme, the programmer should > > think five or six times before overriding it - but when he does, it must > > be assumed that he had a good reason and his changes should be honoured. > > Exactly. > Let me try to explain what I mean with an EXTREME example. Say you are coding the control system for a nuclear power station. Now 99% of your screen is showing the current values for things and with some sliders the operators can adjust some of the equipment settings to ensure that everything remains normal. For almost all times this is ALL there is to it. But there on one side is a few critical values, these ones won't just be changed by adjusting one thing, if they are outside tolerance values then that means a trained expert will need to adjust probably 80% of those sliders to very specific settings to deal with what is in fact an emergency. So when one of those goes out of tolerable range you start by activating every alarm in the building, syrens howling, strobe lights flashing the works. But on screen you do NOT want everything highlighted. What you DO want is for the area around the specific value that triggered the problem to start cycling through red-green-blue-orange-purple and some more colours at a fairly high rate so the operator your alarm woke up will INSTANTLY see which value is out of range and can start fixing it immediately. You don't want to pop up a dialog - clicking ok means it takes longer before he starts adjusting the parameters, but you MUST highlight THAT specific element in a way that should NEVER happen otherwise. The element may be a TEdit on a tgroupbox. Now if an emergency exists and you start colour-flashing the tgroupbox to draw attention to the RIGHT tedit but a theme overrides your colour calls so it doesn't flash and the whole town is flattened before the operator finds the right value (he cannot fix the problem until he knows WHAT the problem is) - well the whole theory just went up in smoke (as did the town). In a non computerized nuclear power station, a big LED would have flashed below the dial with the out of sync value, in a computerized version you HAVE to find a way of getting exactly the same kind of notification and theme must not prevent you from doing it, especially since computerising has so many other usefull advantages (a computer could solve simpler cases itself, like automatically increasing cooling if the temperature rises by a few degrees) in other words, a computerized interface is a good idea - but it MUST be able to override the theme when needed. Yes this is probably the most extreme example there is but it is a very real one, and just because most of us are not coding nuclear reactor controls doesn't mean that our reasons for occasionally having to FORCE colors or fonts are not good ones. A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Grids fixes
The attached fixes two problems I noticed that were exposed with a small
display area for a grid:
1. A range check error if compiled with checks on
2. A hang on scrolling two a particular cell if it is not possible to
show all of the cell
Colin
diff -uNr lazarus/lcl/grids.pas /dos/fpc/lazarus.w/lcl/grids.pas
--- lazarus/lcl/grids.pas 2006-02-25 12:29:24.0 +
+++ /dos/fpc/lazarus.w/lcl/grids.pas 2006-03-04 12:53:48.0 +
@@ -2162,7 +2162,8 @@
{$endif}
ScrollInfo.nMin := 0;
ScrollInfo.nMax := ARange;
-ScrollInfo.nPage := APage;
+if aPage > 0 then
+ ScrollInfo.nPage := APage;
SetScrollInfo(Handle, Which, ScrollInfo, True);
end;
end;
@@ -2308,19 +2309,21 @@
Xinc:=0;
if Rnew.Left + FGCache.TLColOff < FGCache.FixedWidth then Xinc:=-1
-else if RNew.Right + FGCache.TLColOff > FGCache.ClientWidth then XInc:=1;
+else if (RNew.Right + FGCache.TLColOff > FGCache.ClientWidth)
+and (RNew.Left + FGCache.TLColOff - GetColWidths(aCol) >= FGCache.FixedWidth) then XInc:=1;
+// Only scroll left if the left edge of the cell does not become invisible as a result
Yinc:=0;
if RNew.Top + FGCache.TLRowOff < FGCache.FixedHeight then Yinc:=-1
-else if RNew.Bottom + FGCache.TLRowOff > FGCache.ClientHeight then YInc:=1;
+else if (RNew.Bottom + FGCache.TLRowOff > FGCache.ClientHeight)
+and (RNew.Top + FGCache.TLRowOff - GetRowHeights(aRow) >= FGCache.FixedHeight) then YInc:=1;
+// Only scroll up if the top edge of the cell does not become invisible as a result
with FTopLeft do
if ((XInc=0)and(YInc=0)) or // the cell is already visible
((X=aCol)and(Y=aRow)) or // the cell is visible by definition
((X+XInc<0)or(Y+Yinc<0)) or // topleft can't be lower 0
((X+XInc>=ColCount)) or // leftmost column can't be equal/higher than colcount
- ((Y+Yinc>=RowCount)) or // topmost column can't be equal/higher than rowcount
- ((XInc>0)and(X=aCol)and(GetColWidths(aCol)>FGCache.ClientWidth)) or
- ((YInc>0)and(Y=aRow)and(GetRowHeights(aRow)>FGCache.ClientHeight))
+ ((Y+Yinc>=RowCount)) // topmost column can't be equal/higher than rowcount
then
Break;
Inc(FTopLeft.x, XInc);
Re: [lazarus] setColor part 3
Hi, Am Samstag, den 04.03.2006, 20:00 +0200 schrieb A.J. Venter: > > >gtk does the right thing by letting the programmer register "style > > >properties" for a widget class. These names can then be used in themes > > >and gtk will assign the theme color to the style property of the widgets > > >of that class on runtime. > > > > > >I know that it usually depends on the target audience whether it's ok to > > >take shortcuts like hardcoding colors (if your program is to be used by > > >an internal group of 5 people, new people never enter, and none of them > > >has color blindness, sure, hardcode red all you like). _But_ when > > >designing a framework, that is the wrong way to take because they affect > > >all the users there are. > > > What you are saying is correct, but not absolutely so. There are exceptions > to > every rule and the fact is programmers MUST have the capacity to sometimes > enforce certain look and feel changes regardless of themes because themes are > always generic (they are meant to apply to all apps) and sometimes a program > is doing something which is simply specific to that program and the > programmer needs a way of visually explaining a concept to users which simply > does not exist in any theming system. Yes, when it is too new a feature to be considered in the theming system yet, I agree. > Take tappytux for example (the program which was the reason why I started the > gtk2 font setting patches). Number one requested feature from users was: make > the text entry bar at the bottom HUGE. > > This was not MY choice, it was THEIR choice. This was not something that > could > be done for EVERY tedit in the program, but it HAD to be done for THAT tedit > - because the nature of the program was such that, that "entry bar" had to be > really big and accentuated. > Why ? Because the program is for children, and it's a game - and people who > only learned to read a month ago needs to be able to read what they type in > there at a single glance. > The rest of the program they have TIME to spell out letters, if they have to > do it there they will never learn not to have to (at least not from the > program which is supposed to have been written to help teach them this) > because they will simply go game over before they finish the first word. > > See what I am getting at ? It's partially intended audience but it's also > purpose of the program, sometimes a programmer needs to be able to enforce > some things in the look and feel department. Yes, but not colors. It's just getting too hairy. Since humans settled down and have no natural enemies anymore, over time the same will happen to us that happened to our pets: we lose color sight. Over a short or a long period, we do. Evolution hates wasting effort on unused gadgets :) oops, getting off-track :) > Finally there is the simple reality that despite the lack of credit popular > culture gives us in this regard nearly all programmers are highly creative > people. I know and I restrain myself every day to actually use the ... stuff that is there already instead of rewriting everything :) > We LIKE to design interfaces and we like to be a little bit artistic > when we do, and there is nothing wrong with that. If it's within limits, it's ok. (Minimum) Font sizes and colors are entirely in the user's realm though and we just can't magically set that to a constant value for everyone. It just doesn't work :) But if it's with layouting existing widgets and clustering them in different windows and such, sure, all freedom there. But _for example_ creating a new-and-improved kind of "knob" control instead of a slider is off-limits. > Since we are the creators, > we should be able to design something which is visually pleasing to us ? Yes, so use style properties (and maybe propose defaults for them to gtk) and fall back to your defaults in code if missing in theme. I'm not saying that design shouldn't be done. Design is important. Some stuff is outside of our realm though, like font size and color. > > I am not saying we should force users to use bright-red buttons (and I know > that green-red as distinguishing features is a horrible thing to do to users > since about 8% of men cannot distinguish them), but I am saying that we > SHOULD be able to sometimes say "This is the main headline part of my main > screen - I would really like it if it was in Mincho Gothic font in blue > letters on a cream colored button -because it is not SUPPOSED to be the same > as the other buttons" - and that I believe is entirely a good thing, and > something I encourage in my trainee's. Yes, so make a class "FooHeadline" or so that does that and defaults to those colors and font (the actual font can even be fixed, not the size though) and font size, but overrideable by user gtkrc config file / theme. > Programmer designs should never detract from usability, but we should still > be > able to employ a little bit of c
Re: [lazarus] setColor part 3
Hi, Am Samstag, den 04.03.2006, 18:11 +0100 schrieb darekm: > Danny Milosavljevic wrote: > > >Hi, > > > >Am Freitag, den 03.03.2006, 23:10 +0100 schrieb darekm: > > > > > >>[...] > >>If I want (as programmer) to one of buttons will be red, user should'n > >>change it by change theme > >> > >> > > > >I merely react to this grossly out of context (so please forgive me), > >but I just can't resist... > > > >Did you really mean what I read you to mean? > > > >Many (and I mean MANY) people can't even _see_ red (but can see colors > >that somewhat resemble it), so they _have_ to change it... others don't > >like the color red because of psychic problems (after witnessing > >accidents, ...) (especially big red areas on buttons that look like a > >puddle of blood that flows around until it reaches some obstacle). > >Others don't like it because of other reasons. > >Low-color displays (over modem lines etc) have 256 color limitations, > >which makes hardcoded color values a PITA, because they eat up palette > >entries for _all_ applications and in the end you can't read a thing. > >(not mentioning black-and-white displays here because they got kind of > >rare) > > > >http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm > > > >Let's not go back to the dark old times where the programmer decided > >what was good and the user needed to eat it, whether he wants to or not. > >Also, nowadays, we usually do have some processor cycles to spare for > >doing the right thing. > > > >gtk does the right thing by letting the programmer register "style > >properties" for a widget class. These names can then be used in themes > >and gtk will assign the theme color to the style property of the widgets > >of that class on runtime. It's similar but more flexible to the borland pascal turbo vision palette approach btw (but uses strings as ids, not integers, and is per-class) > > > >I know that it usually depends on the target audience whether it's ok to > >take shortcuts like hardcoding colors (if your program is to be used by > >an internal group of 5 people, new people never enter, and none of them > >has color blindness, sure, hardcode red all you like). _But_ when > >designing a framework, that is the wrong way to take because they affect > >all the users there are. > > > > > > > > Yes, You have right, > user should have possibility to change color > but primary programmer set up all controls > if I make button for alerts or erase (or other important or unusual > things) I make it different Yes, you register style properties like "alert-color" and "erase-color" and fallback if those are not defined in the theme after all for your class. Having a published Color property in TControl kind of defeats that though. Better have a list of style property names/types there. like TControl StyleList alert-color Color erase-color Color of course I don't know about mswin32... do they even have a mechanism like that? I tend to think so, they added "theming" with mswinxp, right? And qt surely has the same thing somehow... It's really the obvious way to just abstract out style the same way html did with css too... > > when user change theme they should'n make back all controls similar, he > should change it in different way I assume you mean there should be a class "alert control" and a class "normal control". All alert controls surely have to look the same to each other or else it wouldn't be ... well... alerting ... Or, if you wish, "alertable control" which can be both depending on internal state. > > When I can (but I can't) done step one, then I will do step two. What is step 1? You can derive any kind of gtk widget from an existing widget class, give it new properties and handle it differently in the theme (theme value selections are per widget name and/or widget class name and/or style property name and/or extra "detail" field internal to the drawer - he passes that when calling the drawing functions, it can't get much more flexible than that ;)) like, widget_class "*Alert*" style "foo" widget_class "*Erase*" style "bar" or so :) or by name: widget "evolution_folder_frame_tree" style "green" :) > > > Darek > > PS. With the rest: live is not so easy as You write Well, life is hard, especially with UNIX :) But I am thankful to the Gnome guys that I don't have to cope with unusable (X, motif, win32, ) apps anymore... only a handful crashprone apps left (filemanager, window manager, panel), Xfce replacing them for me :) If you mean that doing the right thing is hard, then I agree, it is, always, everywhere :) But it should be done. cheers, Danny _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
Hi, Am Samstag, den 04.03.2006, 02:06 +0100 schrieb Mattias Gaertner: > On Fri, 03 Mar 2006 23:10:41 +0100 > darekm <[EMAIL PROTECTED]> wrote: > > >[...] > > >>>A button under gtk1 is an area, not just the frame. Some themes define > > >a >>simple darkened area when presses, some some define whole images > > >(e.g. >>round buttons). Maybe gtk2 has more possibilities for > > >TSpeedButton. >> > > >>> > > > > Interesting are there possibilities, which we can use in all OS, of > > course we can implement all myself, but we are limited > > by LCL API, for example now I can't change color of shadow (tButton have > > not thous properties) > > I think, that we should implement more flexible widgets, not so > > dependent from desired library (GTK, WIN, QT) > > Yes, but then it will be a TButtonPlus. A normal TButton is the normal > button of the theme. > > > >[...] > > >I don't know, what windows can do with DrawFrameControl, but under gtk it > > >draws an area in a specific style. If this is a button style, and the > > >theme defines an image, it paints it. > > > > > If I want (as programmer) to one of buttons will be red, user should'n > > change it by change theme > > Correct. But if you want a 'red' button, then you want a custom drawn > button, not a TButton. > If 'red' buttons are needed that often, then we should add a > TCustomDrawnButton (or whatever name fits) with properties like Color, > Frame, BorderWidth, TextAlignment, WordWrap, ... . > This has five advantages: > - the button will really look the same under all platforms I hope that it is clear that a button that looks the same under all platforms is a _disadvantage_. The button of random app X should adapt to the desktop environment in use, otherwise it looks out of place. Just look at the java apps around. Everywhere, no matter if on mswin32 or unix or mac, just everywhere, (our) java swing gui is ugly. It just looks the same everywhere, which is 1) out of place for mswin32 2) out of place for unix and 3) out of place for mac ... not good :) cheers, Danny > - less code in LCL interfaces > - better for smartlinking > - more flexibility > - cleaner design (themed and non themed controls) > > > > >>for tButton all depend from widgets, but for me in tSpeedButton all > > >>should be independent. (GTK has't two widgets) > > >> > > >> > > > > > >Gtk has less widgets, because the idea is combine them. A TGroupbox is a > > >single widget under windows, while under gtk it needs two. For gtk it is > > >pretty normal to put a 'listbox' into a menu. That's why you have more > > >possibilties. > > >A TSpeedButton that is used a button and that draws some rectangles, when > > >all other widgets on the application have shaded round widgets looks very > > >ugly. Especially if you use broken themes, that merely defines images and > > >no colors. > > > > DrawFrameControl not avoid this > > It should. If not, you found a bug. > > > > >>it's only my suggestion > > > > > >What is the trouble with theme painted speedbuttons? > > > > it's not work > > Can you give more details? > > Mattias > > _ > 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] Windows CE support on the IDE
Yury Sidorov wrote: From: "Mattias Gaertner" <[EMAIL PROTECTED]> On Sat, 4 Mar 2006 19:03:25 +0200 "Yury Sidorov" <[EMAIL PROTECTED]> wrote: From: "Michael Van Canneyt" <[EMAIL PROTECTED]> > > > Normally, the 'fpc' binary can choose the correct compiler name > > > based on > > > target OS and CPU setting. That is what it is for in the first > > > place. > > > > I do not see in fpc source that it can run crosscompiler. It only run > > native > > compiler. > > Then it must be corrected; > The function of 'fpc' is to call the correct compiler based on the > CPU/OS target settings. Yes. Let discuss other things. In Windows installation fpc.exe is located in pp\bin\i386-win32 I suppose ppcrossarm.exe and cross binutils need to be located here too. Cross binutils will be prefixed (e.g. arm-wince-as.exe) Lazarus should setup crossbinutils prefix using -XP compiler option (it will look like -XParm-wince- for arm-wince target). Yes, or -XPfpc-i386-win32- for win32 under linux, or many other possibilities. Do you mean -XPi386-win32- ? We need 'target' specific compiler options. With 'target' I do not only mean CPU, OS or LCL target. Maybe this helps at the moment: you can add this to fpc.cfg: # set binutils paths for crosscompiling #IFDEF FPC_CROSSCOMPILING -XParm-wince- #ENDIF Yes. Currently it is possible to setup Lazarus for crosscompiling. But it will break native compiling and we discuss how to make cross and native comiling live together at the same time. For example if you open Win32 project it will compile Win32 app, if you open WinCE project it will compile it too without changing anything in options. I think lazarus support is fine. I will test later tonight (no time now). Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
> >gtk does the right thing by letting the programmer register "style > >properties" for a widget class. These names can then be used in themes > >and gtk will assign the theme color to the style property of the widgets > >of that class on runtime. > > > >I know that it usually depends on the target audience whether it's ok to > >take shortcuts like hardcoding colors (if your program is to be used by > >an internal group of 5 people, new people never enter, and none of them > >has color blindness, sure, hardcode red all you like). _But_ when > >designing a framework, that is the wrong way to take because they affect > >all the users there are. > What you are saying is correct, but not absolutely so. There are exceptions to every rule and the fact is programmers MUST have the capacity to sometimes enforce certain look and feel changes regardless of themes because themes are always generic (they are meant to apply to all apps) and sometimes a program is doing something which is simply specific to that program and the programmer needs a way of visually explaining a concept to users which simply does not exist in any theming system. Take tappytux for example (the program which was the reason why I started the gtk2 font setting patches). Number one requested feature from users was: make the text entry bar at the bottom HUGE. This was not MY choice, it was THEIR choice. This was not something that could be done for EVERY tedit in the program, but it HAD to be done for THAT tedit - because the nature of the program was such that, that "entry bar" had to be really big and accentuated. Why ? Because the program is for children, and it's a game - and people who only learned to read a month ago needs to be able to read what they type in there at a single glance. The rest of the program they have TIME to spell out letters, if they have to do it there they will never learn not to have to (at least not from the program which is supposed to have been written to help teach them this) because they will simply go game over before they finish the first word. See what I am getting at ? It's partially intended audience but it's also purpose of the program, sometimes a programmer needs to be able to enforce some things in the look and feel department. Finally there is the simple reality that despite the lack of credit popular culture gives us in this regard nearly all programmers are highly creative people. We LIKE to design interfaces and we like to be a little bit artistic when we do, and there is nothing wrong with that. Since we are the creators, we should be able to design something which is visually pleasing to us ? I am not saying we should force users to use bright-red buttons (and I know that green-red as distinguishing features is a horrible thing to do to users since about 8% of men cannot distinguish them), but I am saying that we SHOULD be able to sometimes say "This is the main headline part of my main screen - I would really like it if it was in Mincho Gothic font in blue letters on a cream colored button -because it is not SUPPOSED to be the same as the other buttons" - and that I believe is entirely a good thing, and something I encourage in my trainee's. Programmer designs should never detract from usability, but we should still be able to employ a little bit of creativity in interface design - the job of interface design is to take an abstract computing concept of some sort and create a visual analogy that allows non-computer experts to understand what they program does for them and how to achieve their goals with it. This IS a creative process and ingenuity can make all the difference here, especially with custom apps which are often the first to design for a certain concept. To imagine that any theme can be broad enough to handle ALL the problems any program will ever be asked to solve and still be usable as a theme is downright ridiculous. The default should always be to follow the theme, the programmer should think five or six times before overriding it - but when he does, it must be assumed that he had a good reason and his changes should be honoured. Ciao A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
From: "Mattias Gaertner" <[EMAIL PROTECTED]> On Sat, 4 Mar 2006 19:03:25 +0200 "Yury Sidorov" <[EMAIL PROTECTED]> wrote: From: "Michael Van Canneyt" <[EMAIL PROTECTED]> > > > Normally, the 'fpc' binary can choose the correct compiler name > > > based on > > > target OS and CPU setting. That is what it is for in the first > > > place. > > > > I do not see in fpc source that it can run crosscompiler. It only run > > native > > compiler. > > Then it must be corrected; > The function of 'fpc' is to call the correct compiler based on the > CPU/OS target settings. Yes. Let discuss other things. In Windows installation fpc.exe is located in pp\bin\i386-win32 I suppose ppcrossarm.exe and cross binutils need to be located here too. Cross binutils will be prefixed (e.g. arm-wince-as.exe) Lazarus should setup crossbinutils prefix using -XP compiler option (it will look like -XParm-wince- for arm-wince target). Yes, or -XPfpc-i386-win32- for win32 under linux, or many other possibilities. Do you mean -XPi386-win32- ? We need 'target' specific compiler options. With 'target' I do not only mean CPU, OS or LCL target. Maybe this helps at the moment: you can add this to fpc.cfg: # set binutils paths for crosscompiling #IFDEF FPC_CROSSCOMPILING -XParm-wince- #ENDIF Yes. Currently it is possible to setup Lazarus for crosscompiling. But it will break native compiling and we discuss how to make cross and native comiling live together at the same time. For example if you open Win32 project it will compile Win32 app, if you open WinCE project it will compile it too without changing anything in options. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
> less power. It's always like that. The language of a human (and maths) > is just so much more advanced than any computer language, it depresses > me at times. (Assembly language is so primitive that we all stopped > talking it by now, except when we absolutely must do it. But it sure is > "flexible", like an atom - you can use tons of them to build a copy of > the earth, given you have a few billion years time and way too much > patience for your own good :)) > This is a nice argument but it's highly subjective, I find OP to be the computer language CLOSEST to human language, python and java both inherrited too much ascii art from C++ and don't get me STARTED on perl ! One of the things I love about OP (a compiled language) is that it uses mostly WORDS to say things, not symbols, true it's slightly more typing - but it is so much more readable. I always tell my trainee's "If I NEED comments to read your code - it is badly written". Of course I also make it absolutely clear that any program of more than 100 lines which doesn't have comments is pretty much guaranteed to ensure they won't get a permanent position with me, but comments should be there to add clarity NOT to tell you what the code DOES ! That should be obvious just from reading the code. This isn't possible in most languages, in OP it's the default - that is why I think it's such a brilliantly designed language, and the fact is this is something Pascal has boasted since Wirth invented the first version of it. Pascal is probably the only language you can read (large sections of) aloud without stuttering. In other words, by your argument those languages have all failed at exactly the supposed REASON they are interpreted/bytecompiled in the first place. Like I said, it's way too subjective an argument. Now don't get me wrong, I actually rather like python, it has a nice design (although the whole whitespace has meaning thing annoys me a bit) and a fairly decent syntax but the simple reality is that I write code which will end up running on thin clients - that means if a computer slows down to any noticeable degree when running 50 copies of the program at once -it's not good enough, and that rules out python for anything complex. Lazarus works beautifully, I have the language that I like for most work, I can quickly design my GUI's in a RAD environment and the programs run FAST. In the end, Java has spent ten years telling programmers that computers are now so fast that customers don't care about speed anymore, and in ten years computers still haven't gotten that fast and frankly they never will because as computers get faster customers will always expect software to get faster at the same rate (and customers being customers they will expect it to be just as fast on a PII). In the real world, a program that runs slowly and uses up a lot of resources annoys customers and they find another program. Throw in the realities of Africa, and you end up utilising things like thin clients so that those PII's or sometimes even 486's can run modern day apps. Of course they are never quite as fast as on a P4 but they look as fast to users which is good enough -at least for compiled programs which do not abuse all the available resources in the system but use only what they need leaving the rest for the other users. In the end, the choice of a language is personal and not the least of your concerns should be "what language does most of the people on this project know the best", but discounting OP because of what it wasn't in the 80's is ... well uninformed silliness. A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] feature in Lazarus
On Sat, 04 Mar 2006 18:20:42 +0100 darekM <[EMAIL PROTECTED]> wrote: > Can close editor file be added (best at begin) to Recent List > > Why: > I use Lazarus with many open files, > some of them close, some open > when I close by mistake any of older files, then I can't revert it > simple (when it was at Recent list) Sure. I don't use the recent file menu often, so I leave the decision, if this should be added with option or not to the list. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
Mattias Gaertner wrote: On Sat, 4 Mar 2006 19:03:25 +0200 "Yury Sidorov" <[EMAIL PROTECTED]> wrote: From: "Michael Van Canneyt" <[EMAIL PROTECTED]> Normally, the 'fpc' binary can choose the correct compiler name based on target OS and CPU setting. That is what it is for in the first place. I do not see in fpc source that it can run crosscompiler. It only run native compiler. Then it must be corrected; The function of 'fpc' is to call the correct compiler based on the CPU/OS target settings. Yes. Let discuss other things. In Windows installation fpc.exe is located in pp\bin\i386-win32 I suppose ppcrossarm.exe and cross binutils need to be located here too. Cross binutils will be prefixed (e.g. arm-wince-as.exe) Lazarus should setup crossbinutils prefix using -XP compiler option (it will look like -XParm-wince- for arm-wince target). Yes, or -XPfpc-i386-win32- for win32 under linux, or many other possibilities. We need 'target' specific compiler options. With 'target' I do not only mean CPU, OS or LCL target. Maybe this helps at the moment: you can add this to fpc.cfg: # set binutils paths for crosscompiling #IFDEF FPC_CROSSCOMPILING -XParm-wince- #ENDIF Also there should be an option to setup a debugger for each target. There is gdb which allows to remotely debug wince applications from win32 host. Yes. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives I think this effort is already being spent in crossfpc.. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
On Sat, 04 Mar 2006 18:13:14 +0100
darekm <[EMAIL PROTECTED]> wrote:
>[...]
> >Can you give an example?
> >
> function gtkchangedCB( widget: PGtkWidget; data: gPointer) : GBoolean;
> cdecl;
> var
> Mess : TLMessage;
> begin
> if ComponentIsDestroyingHandle(TWinControl(Data))
> or (LockOnChange(PgtkObject(Widget),0)>0) then exit;
> {$IFDEF TraceEvent}
> EventTrace('changed', data);
> {$ENDIF}
>
> Mess.Msg := LM_CHANGED;
> DeliverMessage(Data, Mess);
>
> Result := CallBackDefaultReturn;
> end;
Ok.
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] feature in Lazarus
Can close editor file be added (best at begin) to Recent List Why: I use Lazarus with many open files, some of them close, some open when I close by mistake any of older files, then I can't revert it simple (when it was at Recent list) Darek _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
On Sat, 4 Mar 2006 19:03:25 +0200 "Yury Sidorov" <[EMAIL PROTECTED]> wrote: > From: "Michael Van Canneyt" <[EMAIL PROTECTED]> > > > > Normally, the 'fpc' binary can choose the correct compiler name > > > > based on > > > > target OS and CPU setting. That is what it is for in the first > > > > place. > > > > > > I do not see in fpc source that it can run crosscompiler. It only run > > > native > > > compiler. > > > > Then it must be corrected; > > The function of 'fpc' is to call the correct compiler based on the > > CPU/OS target settings. > > Yes. > > Let discuss other things. > > In Windows installation fpc.exe is located in pp\bin\i386-win32 > I suppose ppcrossarm.exe and cross binutils need to be located here too. > Cross binutils will be prefixed (e.g. arm-wince-as.exe) > Lazarus should setup crossbinutils prefix using -XP compiler option (it > will look like -XParm-wince- for arm-wince target). Yes, or -XPfpc-i386-win32- for win32 under linux, or many other possibilities. We need 'target' specific compiler options. With 'target' I do not only mean CPU, OS or LCL target. Maybe this helps at the moment: you can add this to fpc.cfg: # set binutils paths for crosscompiling #IFDEF FPC_CROSSCOMPILING -XParm-wince- #ENDIF > Also there should be an option to setup a debugger for each target. There > is gdb which allows to remotely debug wince applications from win32 host. Yes. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
Mattias Gaertner wrote:
On Sat, 04 Mar 2006 17:16:46 +0100
darekM <[EMAIL PROTECTED]> wrote:
Mattias Gaertner napisa?(a):
On Sat, 04 Mar 2006 12:39:34 +0100
darekm <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
Darek
PS.Can I comment all EventTrace (or IFDEFs) in gtkcallback.inc, they
slowdown running.
Did you test that?
How much slower?
I've not test but I'm looking for not necessary lines of code
all LCL should follow directive RELEASE and should remove all DebugLN,
assert and log
My application seems to be to slowly (compared to Delphi)
every switch between windows need remarkable time
And why you ask. Even if it need 0.01% time, we can do it on and off as
we need.
We could comment them and delete many of them. But deleting them means,
the next time we search a bug at this place, we have to add them again.
There are many functions where I commented and uncommented the debugging
code a douzand times. Eventually I learned, it saves a lot of time, to
keep some debugging code ready. Other libs like gtk do the same.
but I say IFDEF
Can you give an example?
{$DEFINE TraceEvent}
function gtkchangedCB( widget: PGtkWidget; data: gPointer) : GBoolean;
cdecl;
var
Mess : TLMessage;
begin
if ComponentIsDestroyingHandle(TWinControl(Data))
or (LockOnChange(PgtkObject(Widget),0)>0) then exit;
{$IFDEF TraceEvent}
EventTrace('changed', data);
{$ENDIF}
Mess.Msg := LM_CHANGED;
DeliverMessage(Data, Mess);
Result := CallBackDefaultReturn;
end;
Mattias
_
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] setColor part 3
Danny Milosavljevic wrote: Hi, Am Freitag, den 03.03.2006, 23:10 +0100 schrieb darekm: [...] If I want (as programmer) to one of buttons will be red, user should'n change it by change theme I merely react to this grossly out of context (so please forgive me), but I just can't resist... Did you really mean what I read you to mean? Many (and I mean MANY) people can't even _see_ red (but can see colors that somewhat resemble it), so they _have_ to change it... others don't like the color red because of psychic problems (after witnessing accidents, ...) (especially big red areas on buttons that look like a puddle of blood that flows around until it reaches some obstacle). Others don't like it because of other reasons. Low-color displays (over modem lines etc) have 256 color limitations, which makes hardcoded color values a PITA, because they eat up palette entries for _all_ applications and in the end you can't read a thing. (not mentioning black-and-white displays here because they got kind of rare) http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm Let's not go back to the dark old times where the programmer decided what was good and the user needed to eat it, whether he wants to or not. Also, nowadays, we usually do have some processor cycles to spare for doing the right thing. gtk does the right thing by letting the programmer register "style properties" for a widget class. These names can then be used in themes and gtk will assign the theme color to the style property of the widgets of that class on runtime. I know that it usually depends on the target audience whether it's ok to take shortcuts like hardcoding colors (if your program is to be used by an internal group of 5 people, new people never enter, and none of them has color blindness, sure, hardcode red all you like). _But_ when designing a framework, that is the wrong way to take because they affect all the users there are. Yes, You have right, user should have possibility to change color but primary programmer set up all controls if I make button for alerts or erase (or other important or unusual things) I make it different when user change theme they should'n make back all controls similar, he should change it in different way When I can (but I can't) done step one, then I will do step two. Darek PS. With the rest: live is not so easy as You write _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
From: "Michael Van Canneyt" <[EMAIL PROTECTED]> > > Normally, the 'fpc' binary can choose the correct compiler name based > > on > > target OS and CPU setting. That is what it is for in the first place. > > I do not see in fpc source that it can run crosscompiler. It only run > native > compiler. Then it must be corrected; The function of 'fpc' is to call the correct compiler based on the CPU/OS target settings. Yes. Let discuss other things. In Windows installation fpc.exe is located in pp\bin\i386-win32 I suppose ppcrossarm.exe and cross binutils need to be located here too. Cross binutils will be prefixed (e.g. arm-wince-as.exe) Lazarus should setup crossbinutils prefix using -XP compiler option (it will look like -XParm-wince- for arm-wince target). Also there should be an option to setup a debugger for each target. There is gdb which allows to remotely debug wince applications from win32 host. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
On Sat, 04 Mar 2006 17:56:41 +0100 darekm <[EMAIL PROTECTED]> wrote: > > >>> > >>> > >>simple: when I set color:=clRed then not change color (like in others > >>controls) > >> > >> > > > >The solution is simple: if color<>clBtnFace then paint a custom button. > >The question is only, how to implement it. > >The easiest would be to extend TSpeedButton.Paint with a > > > >if (Color<>clBtnFace) or (... other properties ...) then > > PaintCustomSpeedButton > >else > > PaintThemeButton > > > > > > > > > > > with this patch works (only change order) Applied. Thanks. > two suggestion > 1. is clDefault not better than clBtnFace Delphi compatibility > 2. DrawFrameControl should return inner rectangle (control should know > how fat is frame) Yes. It's a todo. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
simple: when I set color:=clRed then not change color (like in others
controls)
The solution is simple: if color<>clBtnFace then paint a custom button.
The question is only, how to implement it.
The easiest would be to extend TSpeedButton.Paint with a
if (Color<>clBtnFace) or (... other properties ...) then
PaintCustomSpeedButton
else
PaintThemeButton
with this patch works (only change order)
two suggestion
1. is clDefault not better than clBtnFace
2. DrawFrameControl should return inner rectangle (control should know
how fat is frame)
Darek
Index: include/speedbutton.inc
===
--- include/speedbutton.inc (wersja 8862)
+++ include/speedbutton.inc (kopia robocza)
@@ -395,15 +395,13 @@
Canvas.Frame3d(PaintRect, 1, xBevel);
InflateRect(PaintRect, -1, -1);
end;}
- if not Transparent then begin
-Canvas.Brush.Color := Color;
-Canvas.FillRect(PaintRect);
- end;
// do not draw anything if flat and mouse not in control (simplified)
- if (FLastDrawFlags and DFCS_FLAT) = 0 then
+ if (FLastDrawFlags and DFCS_FLAT) = 0 then begin
DrawFrameControl(Canvas.GetUpdatedHandle([csBrushValid,csPenValid]),
PaintRect, DFC_BUTTON, FLastDrawFlags);
+ InflateRect(PaintRect, -1, -1);
+ end;
//writeln('TCustomSpeedButton.Paint ',Name,':',ClassName,'
Parent.Name=',Parent.Name,
// ' DFCS_BUTTONPUSH=',FLastDrawFlags and DFCS_BUTTONPUSH,
@@ -411,6 +409,10 @@
// ' DFCS_INACTIVE=',FLastDrawFlags and DFCS_INACTIVE,
// ' DFCS_FLAT=',FLastDrawFlags and DFCS_FLAT,
// '');
+ if not Transparent and (color<>clBtnFace) then begin
+Canvas.Brush.Color := Color;
+Canvas.FillRect(PaintRect);
+ end;
GlyphWidth:= TButtonGlyph(FGlyph).Glyph.Width;
if TButtonGlyph(FGlyph).NumGlyphs > 1 then
Re: [lazarus] Windows CE support on the IDE
On Sat, 4 Mar 2006, Yury Sidorov wrote: > From: "Michael Van Canneyt" <[EMAIL PROTECTED]> > > From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > > > > > Now onto the problem. How can we add support for Windows CE on > > > > the > > > > IDE? > > > > > > > > It behaves differently then other widgetsets on some aspects: > > > > > > > > - The compiler it uses has a diferent name, it´s called > > > > ppcrossarm.exe > > > > and must be from 2.1.x branch. Do we need a extra field to put > > > > the > > > > path > > > > to the cross compiler? > > > > > > Can we use 'fpc' with some option? > > > > No, ppcrossarm.exe should be called. > > > Normally, the 'fpc' binary can choose the correct compiler name based on > > target OS and CPU setting. That is what it is for in the first place. > > I do not see in fpc source that it can run crosscompiler. It only run native > compiler. Then it must be corrected; The function of 'fpc' is to call the correct compiler based on the CPU/OS target settings. Michael.
Re: [lazarus] Object pascal a "Modern Language"
Object Pascal is a long way from Wirth's pascal or even from turbo pascal. People who say it is a backward language or dead language don't know object pascal, teach C++, and think pascal is algol. The mass of interpreted languages out do indeed have interesting features. Very nice features. But it does mean without the speed of todays hard drives and computers you have serious problems. And sometimes you still have problems. That said You can write some wonderfully difficult to follow scripts in them. They are also good as embedded scripting languages for your application. Notice it took MS a while but they finally opened up and made it where you could embed a number of scripting systems instead of only VB. As i remember Java, i haven't looked at it in about 6 years, there were a number of features which just plain couldn't happen without an interperter. Many of the early compilers were p-code compilers which then required an interperter, i think i had one on my first ibm compatible when i booted under cpm. But everyone always knew java was slow. It wasn't meant to be able to be your primary language for large projects. But as we now have computers 1000s of times faster than my first one, and tremendously faster than when java came out we are getting lazy. I mean when people on a regular basis make arrays that are larger than my early computers had in all of their memory or could even address. Of course, one place i worked at used to sell computers with 5 megabyte hard drives and tell people "that's more than you'll ever need". I had a difficult time with that since i had a HUGE 10 megabytes of stuff on floppy disks. ---dale _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
From: "Mattias Gaertner" <[EMAIL PROTECTED]> Michael Van Canneyt <[EMAIL PROTECTED]> wrote: On Sat, 4 Mar 2006, Yury Sidorov wrote: > From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > > > Now onto the problem. How can we add support for Windows CE on the > > > IDE? > > > > > > It behaves differently then other widgetsets on some aspects: > > > > > > - The compiler it uses has a diferent name, it´s called > > > ppcrossarm.exe > > > and must be from 2.1.x branch. Do we need a extra field to put the > > > path > > > to the cross compiler? > > > > Can we use 'fpc' with some option? > > No, ppcrossarm.exe should be called. Normally, the 'fpc' binary can choose the correct compiler name based on target OS and CPU setting. That is what it is for in the first place. 'fpc -Twince' calls ppcrossarm.exe, right? When will this fail? No. fpc always calls native compiler (e.g. ppc386.exe in Win32). Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
From: "Michael Van Canneyt" <[EMAIL PROTECTED]> From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > Now onto the problem. How can we add support for Windows CE on the > > IDE? > > > > It behaves differently then other widgetsets on some aspects: > > > > - The compiler it uses has a diferent name, it´s called > > ppcrossarm.exe > > and must be from 2.1.x branch. Do we need a extra field to put the > > path > > to the cross compiler? > > Can we use 'fpc' with some option? No, ppcrossarm.exe should be called. Normally, the 'fpc' binary can choose the correct compiler name based on target OS and CPU setting. That is what it is for in the first place. I do not see in fpc source that it can run crosscompiler. It only run native compiler. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
On Sat, 4 Mar 2006 17:33:55 +0100 (CET) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Sat, 4 Mar 2006, Yury Sidorov wrote: > > > From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > > > > > Now onto the problem. How can we add support for Windows CE on the > > > > IDE? > > > > > > > > It behaves differently then other widgetsets on some aspects: > > > > > > > > - The compiler it uses has a diferent name, it´s called > > > > ppcrossarm.exe > > > > and must be from 2.1.x branch. Do we need a extra field to put the > > > > path > > > > to the cross compiler? > > > > > > Can we use 'fpc' with some option? > > > > No, ppcrossarm.exe should be called. > > Normally, the 'fpc' binary can choose the correct compiler name based on > target OS and CPU setting. That is what it is for in the first place. 'fpc -Twince' calls ppcrossarm.exe, right? When will this fail? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
On Sat, 04 Mar 2006 17:16:46 +0100 darekM <[EMAIL PROTECTED]> wrote: > Mattias Gaertner napisa?(a): > > On Sat, 04 Mar 2006 12:39:34 +0100 > > darekm <[EMAIL PROTECTED]> wrote: > > > > > >> Mattias Gaertner wrote: > >> > >> > >>> > >>> > >>> > Darek > > PS.Can I comment all EventTrace (or IFDEFs) in gtkcallback.inc, they > slowdown running. > > > > >>> Did you test that? > >>> How much slower? > >>> > >>> > >>> > >> I've not test but I'm looking for not necessary lines of code > >> > >> all LCL should follow directive RELEASE and should remove all DebugLN, > >> assert and log > >> > >> My application seems to be to slowly (compared to Delphi) > >> > >> every switch between windows need remarkable time > >> > >> And why you ask. Even if it need 0.01% time, we can do it on and off as > > > >> we need. > >> > > > > We could comment them and delete many of them. But deleting them means, > > the next time we search a bug at this place, we have to add them again. > > There are many functions where I commented and uncommented the debugging > > code a douzand times. Eventually I learned, it saves a lot of time, to > > keep some debugging code ready. Other libs like gtk do the same. > > > but I say IFDEF Can you give an example? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
On Sat, 4 Mar 2006, Yury Sidorov wrote: > From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > > > Now onto the problem. How can we add support for Windows CE on the > > > IDE? > > > > > > It behaves differently then other widgetsets on some aspects: > > > > > > - The compiler it uses has a diferent name, it´s called > > > ppcrossarm.exe > > > and must be from 2.1.x branch. Do we need a extra field to put the > > > path > > > to the cross compiler? > > > > Can we use 'fpc' with some option? > > No, ppcrossarm.exe should be called. Normally, the 'fpc' binary can choose the correct compiler name based on target OS and CPU setting. That is what it is for in the first place. Michael.
Re: [lazarus] Windows CE support on the IDE
On Sat, 4 Mar 2006 18:16:40 +0200 "Yury Sidorov" <[EMAIL PROTECTED]> wrote: > From: "Mattias Gaertner" <[EMAIL PROTECTED]> > > >> Now onto the problem. How can we add support for Windows CE on the IDE? > >> > >> It behaves differently then other widgetsets on some aspects: > >> > >> - The compiler it uses has a diferent name, it´s called ppcrossarm.exe > >> and must be from 2.1.x branch. Do we need a extra field to put the path > >> to the cross compiler? > > > > Can we use 'fpc' with some option? > > No, :( > ppcrossarm.exe should be called. > I think there should be list of cross compilers available in environment > options. So a user can setup cross compiler executable for each target CPU > if needed. I will add it. > >> - You can compile Windows CE softwares for various different > >> architectures. I see currently no place to set the target architecture. > >> > >> On Tools -> Configure Build Lazarus there is a option to set the OS, > >> perhaps we need to add a option to choose the architecture? > > > > Yes. > > Lazarus should call corresponding crosscompiler if target CPU is different > from host CPU. Yes. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Windows CE support on the IDE
From: "Mattias Gaertner" <[EMAIL PROTECTED]> Now onto the problem. How can we add support for Windows CE on the IDE? It behaves differently then other widgetsets on some aspects: - The compiler it uses has a diferent name, it´s called ppcrossarm.exe and must be from 2.1.x branch. Do we need a extra field to put the path to the cross compiler? Can we use 'fpc' with some option? No, ppcrossarm.exe should be called. I think there should be list of cross compilers available in environment options. So a user can setup cross compiler executable for each target CPU if needed. - You can compile Windows CE softwares for various different architectures. I see currently no place to set the target architecture. On Tools -> Configure Build Lazarus there is a option to set the OS, perhaps we need to add a option to choose the architecture? Yes. Lazarus should call corresponding crosscompiler if target CPU is different from host CPU. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
Mattias Gaertner napisał(a): On Sat, 04 Mar 2006 12:39:34 +0100 darekm <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: Darek PS.Can I comment all EventTrace (or IFDEFs) in gtkcallback.inc, they slowdown running. Did you test that? How much slower? I've not test but I'm looking for not necessary lines of code all LCL should follow directive RELEASE and should remove all DebugLN, assert and log My application seems to be to slowly (compared to Delphi) every switch between windows need remarkable time And why you ask. Even if it need 0.01% time, we can do it on and off as we need. We could comment them and delete many of them. But deleting them means, the next time we search a bug at this place, we have to add them again. There are many functions where I commented and uncommented the debugging code a douzand times. Eventually I learned, it saves a lot of time, to keep some debugging code ready. Other libs like gtk do the same. but I say IFDEF
Re: [lazarus] Windows CE support on the IDE
On Sat, 04 Mar 2006 12:42:31 -0300 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > Hello, > > Today or on the next days I will be sending patches to implement basic > structures for the Windows CE LCL Interface. > > At the moment TApplication and TCustomForm have basics implemented. A > screenshot of the first lazarus - wince gui software is here: > http://wiki.lazarus.freepascal.org/index.php/Windows_CE_Interface > > Now onto the problem. How can we add support for Windows CE on the IDE? > > It behaves differently then other widgetsets on some aspects: > > - The compiler it uses has a diferent name, it´s called ppcrossarm.exe > and must be from 2.1.x branch. Do we need a extra field to put the path > to the cross compiler? Can we use 'fpc' with some option? > - You can compile Windows CE softwares for various different > architectures. I see currently no place to set the target architecture. > > On Tools -> Configure Build Lazarus there is a option to set the OS, > perhaps we need to add a option to choose the architecture? Yes. > Here is the batch script I use to compile LCL for Windows CE: > > PATH=C:\Programas\lazarus13\pp\bin\i386-win32;c:\Programas\arm > make lcl LCL_PLATFORM=wince PP=ppcrossarm.exe CPU_TARGET=arm > OS_TARGET=wince > > And the script I use to compile software: > > PATH=C:\Programas\lazarus13\pp\bin\i386-win32;c:\Programas\arm > ppcrossarm.exe -Twince -FuC:\Programas\fpc21\rtl\units\arm-wince > -FDC:\Programas\arm -XParm-wince- test.pas > ppcrossarm.exe -Twince -FuC:\programas\lazarus\lcl\units\arm-wince > -FuC:\programas\lazarus\lcl\units\arm-wince\wince > -FuC:\Programas\fpc21\rtl\units\arm-wince -FDC:\Programas\arm > -XParm-wince- windowtest.pas > > The goal is to be able to recompile LCL with the cross compiler without > messing win32 lcl, and also compile software for wince using the IDE. Yes. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Windows CE support on the IDE
Hello, Today or on the next days I will be sending patches to implement basic structures for the Windows CE LCL Interface. At the moment TApplication and TCustomForm have basics implemented. A screenshot of the first lazarus - wince gui software is here: http://wiki.lazarus.freepascal.org/index.php/Windows_CE_Interface Now onto the problem. How can we add support for Windows CE on the IDE? It behaves differently then other widgetsets on some aspects: - The compiler it uses has a diferent name, it´s called ppcrossarm.exe and must be from 2.1.x branch. Do we need a extra field to put the path to the cross compiler? - You can compile Windows CE softwares for various different architectures. I see currently no place to set the target architecture. On Tools -> Configure Build Lazarus there is a option to set the OS, perhaps we need to add a option to choose the architecture? Here is the batch script I use to compile LCL for Windows CE: PATH=C:\Programas\lazarus13\pp\bin\i386-win32;c:\Programas\arm make lcl LCL_PLATFORM=wince PP=ppcrossarm.exe CPU_TARGET=arm OS_TARGET=wince And the script I use to compile software: PATH=C:\Programas\lazarus13\pp\bin\i386-win32;c:\Programas\arm ppcrossarm.exe -Twince -FuC:\Programas\fpc21\rtl\units\arm-wince -FDC:\Programas\arm -XParm-wince- test.pas ppcrossarm.exe -Twince -FuC:\programas\lazarus\lcl\units\arm-wince -FuC:\programas\lazarus\lcl\units\arm-wince\wince -FuC:\Programas\fpc21\rtl\units\arm-wince -FDC:\Programas\arm -XParm-wince- windowtest.pas The goal is to be able to recompile LCL with the cross compiler without messing win32 lcl, and also compile software for wince using the IDE. thanks, Felipe _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
> No, if you need pointer _arithmetic_ you are doing it wrong or using a > language that is assembly in disguise. Pointers itself are fine and > dandy, but don't *(x + 3 * i + 2) = *(y - 3);. Would you talk like that > to a human? No? Why talk like that to a computer then? It's just a sign > that something in the language is broken when you need to do stuff like > that (except when writing a heap memory manager, I guess). But I mean > when you need to do it like all the time, like for arrays (hello C :)). > Also, by doing stuff like that you throw all bounds checking out of the > window, so you could as well write it in assembly and spare yourself the > hassle of using a compiler that brags all the time except where it > matters. I've decided that C is now officially the "learning" language for universities. Students will now learn about all sorts of computer memory management in C, but C will never be used for any practical purpose. It serves as the teaching language of "what language we should never use but teaches us a lot about the memory in a computer". It also serves as a language which makes a programmer feel happy "I'm glad I learned C because it was 8 times harder just to create a string, and now I'm ahead 8 times by not using C. If I wouldn't have learned C I wouldn't have known I was 8 times ahead." > > As an aside, I remain adamant that anybody who writes a free software/open > > source program in Java is being foolish. What is the POINT of a free software > > program that REQUIRES a non-free program just to RUN ? > > I've also wondered about that.. I mean there is gcj and mono and such, > but... why not do something that is better but our own thing... I've > looked at parrot for a vm but it's tailored for interpreted languages > only. sigh. It's the same as Delphi users doing the JEDI project and allowing borland to use their code without Jedi getting paid. Borland is smiling and laughing all the way to the bank while Jedi developers are smiling, but not laughing to the bank. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] turboCASH on Lazarus "proof of concept"
Mattias Gaertner wrote: > On Tue, 28 Feb 2006 12:57:32 -0300 > Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > > >> [...] >> If you Linux guys (Even the Lazarus on Windows guys) - Could do the >> following : >> >> i) Download the TurboCASH/Delphi project. Steal whatever you need >> ii) "Open " a set of books simply by connecting to the TurboCASH Fro >> bird Database >> > > Where can I find documentation about this 'set of books' of the 'Fro bird > Database'? > There may be some language and spelling issues there - did he perhaps mean "Firebird"? I'm assuming from the description the books would need to already exist from an existing TurboCASH Delphi install. If I'm not mistaken these are the guys who contacted me a year or so ago about the project - since it's similar in some aspects to CBT - but I've had no time to help out. -Tony _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Give FPC/Lazarus a face...
On 3/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Is there a list who is working on FPC/Lazarus, > who is contributor, > who is responsible for sub-system xy, > how many people are working on FPC/Lazarus, > etc. ??? Should we start a Wiki page about this? What could be the name of that page? When the wikies are merged we can have only 1 page for this. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
Hi, Am Samstag, den 04.03.2006, 15:41 +0200 schrieb A.J. Venter: > > > > > > python is a very nice language. > > > Why don't you just write the speed critical parts in C or C++. > > > That's how everyone does it in python. > > > > Showing only that python isn't up to the task. Actually showing that one should use the right tool for the job. i.e. Expressive languages for the high level constructs and fast but horrid languages (= assembly, more or less - that is what C is.) for the low level constructs. > > Just like all these other interpreted languages: .NET, Java... Halfway languages... Trying to get the best of both worlds. Very hard to do but it will show if it's doable or not, so we don't have to try it out to see :) > > > > It's cheating, and they all do it: falling back to compiled > > languaged. My message to the designers of these languages: > > Quit fooling around, and do things right from the start. > > > This does bring up an interesting point, why is it that more and more > languages are becoming interpreted or bytecompiled ? I mean, surely the > python designers could have written platform level compilers for no more > difficulty than to write bytecompilers ? No... afaik it isn't really a bytecompiler either... its mostly interpreted, which brings them a flexibility unparallelled anywhere else except in lisp (which, ironically, is compiled). > Heck they even got jython - compiling to the java vm so they must have had > the > option. > > Instead it offers the choices of bytecompiled or scripted. > Why is source portability not enough ? Why sacrifice so much speed more speed > and power less power. It's always like that. The language of a human (and maths) is just so much more advanced than any computer language, it depresses me at times. (Assembly language is so primitive that we all stopped talking it by now, except when we absolutely must do it. But it sure is "flexible", like an atom - you can use tons of them to build a copy of the earth, given you have a few billion years time and way too much patience for your own good :)) > to get "binary" compatibility (or at least cheat so it looks like that) ? > Of course that is not the only power that gets lost, memory management, > pointers - there is so much these approaches sacrifices, now I know their > designers love to say things like "if you need pointers you are doing it > wrong" No, if you need pointer _arithmetic_ you are doing it wrong or using a language that is assembly in disguise. Pointers itself are fine and dandy, but don't *(x + 3 * i + 2) = *(y - 3);. Would you talk like that to a human? No? Why talk like that to a computer then? It's just a sign that something in the language is broken when you need to do stuff like that (except when writing a heap memory manager, I guess). But I mean when you need to do it like all the time, like for arrays (hello C :)). Also, by doing stuff like that you throw all bounds checking out of the window, so you could as well write it in assembly and spare yourself the hassle of using a compiler that brags all the time except where it matters. > but in my mind that is a cop-out to avoid dealing with the fact that > they make it impossible for programmers to use a truly powerful construct > that can do some pretty amazing things. Well, it really depends on what you are doing. I always found the combination pascal & assembly great because pascal lets you do the highlevel things nicely and safely (i.e. *checked*), and assembly lets you do the dirty details, without any safety, like being able to shoot yourself in the foot every two instructions or so :). > The simple truth is that even java's pseudo implementations of things like > hash tables to get around the fact that in other languages those are done > with pointers aren't good - I have USED java's hash table interface, it's > horrid ! Hash Tables in no way need pointers to be visible. A hash table is so easy a construct.. it's just a normal array. The index into the array is the hash of the key (mod the size of array to prevent out-of-boundness). The value in the array at that index is (key, value). That's it! (The only three weaknesses being 1) you need to find a hash algorithm that doesn't suck _for your data_, 2) the processor cache hates you and will get back at you one of those days :), and 3) resizing requires rehashing usually) Now there are examples for where you mostly do need pointers: trees and lists. The trend for lists goes more to a mixed dynamic array approach - that is, lists of blocks of tons of entries - nowadays (like the inodes are, for example), because the members are more adjacent and the cache likes you more for that (harddisks as well, since they don't need to seek around - it's even worse there). Remaining use for pointers on client side: tree nodes. Not sure if pointer arithmetic is useful there. Guess not. :) > > As I told a SUN employee a few days ago "I will stick with having a t
Re: [lazarus] turboCASH on Lazarus "proof of concept"
On Tue, 28 Feb 2006 12:57:32 -0300 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: >[...] > If you Linux guys (Even the Lazarus on Windows guys) - Could do the > following : > > i) Download the TurboCASH/Delphi project. Steal whatever you need > ii) "Open " a set of books simply by connecting to the TurboCASH Fro > bird Database Where can I find documentation about this 'set of books' of the 'Fro bird Database'? > iii) Set up any grid you like to edit any record you like in TurboCASH > iv) Write a simple report (take any one of ch windows one) > > If we can do the above we can consider Lazarus as a serious proposition. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
Hi, Am Freitag, den 03.03.2006, 23:10 +0100 schrieb darekm: > [...] > If I want (as programmer) to one of buttons will be red, user should'n > change it by change theme I merely react to this grossly out of context (so please forgive me), but I just can't resist... Did you really mean what I read you to mean? Many (and I mean MANY) people can't even _see_ red (but can see colors that somewhat resemble it), so they _have_ to change it... others don't like the color red because of psychic problems (after witnessing accidents, ...) (especially big red areas on buttons that look like a puddle of blood that flows around until it reaches some obstacle). Others don't like it because of other reasons. Low-color displays (over modem lines etc) have 256 color limitations, which makes hardcoded color values a PITA, because they eat up palette entries for _all_ applications and in the end you can't read a thing. (not mentioning black-and-white displays here because they got kind of rare) http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm Let's not go back to the dark old times where the programmer decided what was good and the user needed to eat it, whether he wants to or not. Also, nowadays, we usually do have some processor cycles to spare for doing the right thing. gtk does the right thing by letting the programmer register "style properties" for a widget class. These names can then be used in themes and gtk will assign the theme color to the style property of the widgets of that class on runtime. I know that it usually depends on the target audience whether it's ok to take shortcuts like hardcoding colors (if your program is to be used by an internal group of 5 people, new people never enter, and none of them has color blindness, sure, hardcode red all you like). _But_ when designing a framework, that is the wrong way to take because they affect all the users there are. sigh. cheers, Danny _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Give FPC/Lazarus a face...
Is there a list who is working on FPC/Lazarus, who is contributor, who is responsible for sub-system xy, how many people are working on FPC/Lazarus, etc. ??? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
On Sat, 04 Mar 2006 12:31:05 +0100 darekm <[EMAIL PROTECTED]> wrote: >[...] > I talk about tSpeedButton not tButton A normal TSpeedButton should look like a normal button. Only if you set some custom colors, then it can paint some non theme button. > >>>I don't know, what windows can do with DrawFrameControl, but under gtk > >it >>draws an area in a specific style. If this is a button style, and > >the >>theme defines an image, it paints it. > >>> > >>> > >>> > >>If I want (as programmer) to one of buttons will be red, user should'n > >>change it by change theme > >> > >> > > > >Correct. But if you want a 'red' button, then you want a custom drawn > >button, not a TButton. > >If 'red' buttons are needed that often, then we should add a > >TCustomDrawnButton (or whatever name fits) with properties like Color, > >Frame, BorderWidth, TextAlignment, WordWrap, ... . > >This has five advantages: > >- the button will really look the same under all platforms > >- less code in LCL interfaces > >- better for smartlinking > >- more flexibility > >- cleaner design (themed and non themed controls) > > > > > that's what for is property color, > and maybe order should be different: first without theme and second > (inherited) with. > or (better) tControl should have property - with or without theme The theme is the default. And painting the theme requires only a call to the widgetset, while custom painting requires extra code. I don't see, why a themed control would descend from a non themed control. Or maybe I misunderstood you here? About the Theme property: IMHO this property would be redundant and/or readonly. Can you give an example, where it is needed? > for tButton all depend from widgets, but for me in tSpeedButton all > should be independent. (GTK has't two widgets) > > > > > >>>Gtk has less widgets, because the idea is combine them. A TGroupbox is > >a >>single widget under windows, while under gtk it needs two. For gtk it > >is >>pretty normal to put a 'listbox' into a menu. That's why you have > >more >>possibilties. > >>>A TSpeedButton that is used a button and that draws some rectangles, > >when >>all other widgets on the application have shaded round widgets > >looks very >>ugly. Especially if you use broken themes, that merely > >defines images and >>no colors. > >>> > >>> > >>DrawFrameControl not avoid this > >> > >> > > > >It should. If not, you found a bug. > > > > > > DrawFrameControl use only two function > If (Shadow=GTK_SHADOW_NONE) then > gtk_paint_flat_box(aStyle,aDC.Drawable, > else > gtk_paint_box(aStyle,aDC.Drawable, > > both draw rectangle, > As I know, Style either don't have place to set rounded widgets > It can only set pixmap (that's is only difference to windows) Correct. They look as if they are round, but it's an illusion. Just as Frame3D - the frame is not 3D. But Frame3D only paints a frame without content, while DrawFrameControl draws a whole control. Of course this is an extension to the winapi definition. It is done so, because all the Delphi code using those functions, will look pretty on other platforms. > and we not use this to tButton, then why use it to tSpeedButton TButton has less properties, so it represents the normal button of the widgetset. TSpeedButton has some more features (group, down, flat). > it's only my suggestion > > > >>>What is the trouble with theme painted speedbuttons? > >>> > >>> > >>it's not work > >> > >> > > > >Can you give more details? > > > > > > simple: when I set color:=clRed then not change color (like in others > controls) The solution is simple: if color<>clBtnFace then paint a custom button. The question is only, how to implement it. The easiest would be to extend TSpeedButton.Paint with a if (Color<>clBtnFace) or (... other properties ...) then PaintCustomSpeedButton else PaintThemeButton Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
> > > > python is a very nice language. > > Why don't you just write the speed critical parts in C or C++. > > That's how everyone does it in python. > > Showing only that python isn't up to the task. > Just like all these other interpreted languages: .NET, Java... > > It's cheating, and they all do it: falling back to compiled > languaged. My message to the designers of these languages: > Quit fooling around, and do things right from the start. > This does bring up an interesting point, why is it that more and more languages are becoming interpreted or bytecompiled ? I mean, surely the python designers could have written platform level compilers for no more difficulty than to write bytecompilers ? Heck they even got jython - compiling to the java vm so they must have had the option. Instead it offers the choices of bytecompiled or scripted. Why is source portability not enough ? Why sacrifice so much speed and power to get "binary" compatibility (or at least cheat so it looks like that) ? Of course that is not the only power that gets lost, memory management, pointers - there is so much these approaches sacrifices, now I know their designers love to say things like "if you need pointers you are doing it wrong" but in my mind that is a cop-out to avoid dealing with the fact that they make it impossible for programmers to use a truly powerful construct that can do some pretty amazing things. The simple truth is that even java's pseudo implementations of things like hash tables to get around the fact that in other languages those are done with pointers aren't good - I have USED java's hash table interface, it's horrid ! As I told a SUN employee a few days ago "I will stick with having a truly powerful source-portable fully object oriented language that doesn't practise bondage-and-discipline on style for as long as such languages exist - in short, I will use and promote lazarus - not java" As an aside, I remain adamant that anybody who writes a free software/open source program in Java is being foolish. What is the POINT of a free software program that REQUIRES a non-free program just to RUN ? Ciao A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] ipHTMLPanel Selection paint
On Windows version of Lazarus I added a small part of code in order to
paint selected part of page viewed. it seem it is never called. This
same addition to Linux version of Lazarus does not afect selection is
painted.
Addition made in ipHTML unit about line 8040.
{$IFDEF IP_LAZARUS}
//DebugLn('TIpHtml.PaintSelection PatBlt not implemented');
BitMapToInvert := TBitMap.Create;
BitMapToInvert.Width := R.Right - R.Left;
BitMapToInvert.Height := R.Bottom - R.Top;
BitMapToInvert.Canvas.CopyMode := cmMergePaint;
BitMapToInvert.Canvas.CopyRect( Rect( 0, 0, BitMapToInvert.Width,
BitMapToInvert.Height ), PaintBuffer, R );
PaintBuffer.CopyRect( R, BitMapToInvert.Canvas, Rect( 0, 0,
BitMapToInvert.Width, BitMapToInvert.Height ) );
BitMapToInvert.Free;
{$ELSE}
PatBlt(PaintBuffer.Handle, R.Left, R.Top, R.Right - R.Left, R.Bottom -
R.Top, DSTINVERT);
{$ENDIF}
By default ipHTMLPanel paints selected region (white chars on black
background), but SelectAll methos oes not paint. Project is compiled for
gtk2.
Panagiotis
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
On Sat, 04 Mar 2006 12:39:34 +0100 darekm <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > > > > > >>Darek > >> > >>PS.Can I comment all EventTrace (or IFDEFs) in gtkcallback.inc, they > >>slowdown running. > >> > >> > > > >Did you test that? > >How much slower? > > > > > > I've not test but I'm looking for not necessary lines of code > > all LCL should follow directive RELEASE and should remove all DebugLN, > assert and log > > My application seems to be to slowly (compared to Delphi) > > every switch between windows need remarkable time > > And why you ask. Even if it need 0.01% time, we can do it on and off as > we need. We could comment them and delete many of them. But deleting them means, the next time we search a bug at this place, we have to add them again. There are many functions where I commented and uncommented the debugging code a douzand times. Eventually I learned, it saves a lot of time, to keep some debugging code ready. Other libs like gtk do the same. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
On Sat, 4 Mar 2006, Uwe Grauer wrote: > Matt Henley wrote: > > I belong to a mailing list for a defunt open source chemical process > > simulator (Sim42). Members of the list are now showing interest in > > restarting the effort. It was originally written in python which > > cause some speed issues. Several of the list members (including me) > > suggested freepascal and lazarus. The gentleman spearheading the > > effort sent the following and I would like to know what is the best > > way to respond. I do not know what features define a "modern > > language" and would like to know what points to bring up. > > snip... > > Matt, > > python is a very nice language. > Why don't you just write the speed critical parts in C or C++. > That's how everyone does it in python. Showing only that python isn't up to the task. Just like all these other interpreted languages: .NET, Java... It's cheating, and they all do it: falling back to compiled languaged. My message to the designers of these languages: Quit fooling around, and do things right from the start. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Object pascal a "Modern Language"
Matt Henley wrote: > I belong to a mailing list for a defunt open source chemical process > simulator (Sim42). Members of the list are now showing interest in > restarting the effort. It was originally written in python which > cause some speed issues. Several of the list members (including me) > suggested freepascal and lazarus. The gentleman spearheading the > effort sent the following and I would like to know what is the best > way to respond. I do not know what features define a "modern > language" and would like to know what points to bring up. > snip... Matt, python is a very nice language. Why don't you just write the speed critical parts in C or C++. That's how everyone does it in python. There is no need to port to a language which needs 5-10 times the efford in getting things out. Just my opinion, Uwe _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug in tComboBox
Mattias Gaertner wrote: Darek PS.Can I comment all EventTrace (or IFDEFs) in gtkcallback.inc, they slowdown running. Did you test that? How much slower? I've not test but I'm looking for not necessary lines of code all LCL should follow directive RELEASE and should remove all DebugLN, assert and log My application seems to be to slowly (compared to Delphi) every switch between windows need remarkable time And why you ask. Even if it need 0.01% time, we can do it on and off as we need. Darek _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor part 3
Mattias Gaertner wrote: On Fri, 03 Mar 2006 23:10:41 +0100 darekm <[EMAIL PROTECTED]> wrote: [...] A button under gtk1 is an area, not just the frame. Some themes define a >>simple darkened area when presses, some some define whole images (e.g. >>round buttons). Maybe gtk2 has more possibilities for TSpeedButton. >> Interesting are there possibilities, which we can use in all OS, of course we can implement all myself, but we are limited by LCL API, for example now I can't change color of shadow (tButton have not thous properties) I think, that we should implement more flexible widgets, not so dependent from desired library (GTK, WIN, QT) Yes, but then it will be a TButtonPlus. A normal TButton is the normal button of the theme. I talk about tSpeedButton not tButton [...] I don't know, what windows can do with DrawFrameControl, but under gtk it draws an area in a specific style. If this is a button style, and the theme defines an image, it paints it. If I want (as programmer) to one of buttons will be red, user should'n change it by change theme Correct. But if you want a 'red' button, then you want a custom drawn button, not a TButton. If 'red' buttons are needed that often, then we should add a TCustomDrawnButton (or whatever name fits) with properties like Color, Frame, BorderWidth, TextAlignment, WordWrap, ... . This has five advantages: - the button will really look the same under all platforms - less code in LCL interfaces - better for smartlinking - more flexibility - cleaner design (themed and non themed controls) that's what for is property color, and maybe order should be different: first without theme and second (inherited) with. or (better) tControl should have property - with or without theme for tButton all depend from widgets, but for me in tSpeedButton all should be independent. (GTK has't two widgets) Gtk has less widgets, because the idea is combine them. A TGroupbox is a single widget under windows, while under gtk it needs two. For gtk it is pretty normal to put a 'listbox' into a menu. That's why you have more possibilties. A TSpeedButton that is used a button and that draws some rectangles, when all other widgets on the application have shaded round widgets looks very ugly. Especially if you use broken themes, that merely defines images and no colors. DrawFrameControl not avoid this It should. If not, you found a bug. DrawFrameControl use only two function If (Shadow=GTK_SHADOW_NONE) then gtk_paint_flat_box(aStyle,aDC.Drawable, else gtk_paint_box(aStyle,aDC.Drawable, both draw rectangle, As I know, Style either don't have place to set rounded widgets It can only set pixmap (that's is only difference to windows) and we not use this to tButton, then why use it to tSpeedButton it's only my suggestion What is the trouble with theme painted speedbuttons? it's not work Can you give more details? simple: when I set color:=clRed then not change color (like in others controls) Mattias _ 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] setColor part 3
On Sat, 4 Mar 2006 08:34:26 +0100 Micha Nelissen <[EMAIL PROTECTED]> wrote: > On Sat, 4 Mar 2006 08:06:24 +0100 > Micha Nelissen <[EMAIL PROTECTED]> wrote: > > > On Sat, 4 Mar 2006 02:06:46 +0100 > > Mattias Gaertner <[EMAIL PROTECTED]> wrote: > > > > > If 'red' buttons are needed that often, then we should add a > > > TCustomDrawnButton (or whatever name fits) with properties like Color, > > > > TSpeedButton ? Yes, that's indeed a better ancestor for custom drawn buttons. > I mean we're getting a lot of buttons this way, with mostly redundant > (duplicate) code ... :-/ They would be put even in the same unit. I'm sure, we can share the code. What about this: TSpeedButton is already painted by the LCL. If the Color property is not the default, it can switch to custom drawing (Lines instead of Frame3D/DrawFrameControl). Then we can also add properties BorderWidth, Margin, gradient, or whatever is desired. And those who want a 'red' button, we can tell to use a TSpeedButton instead. Then the widgetsets need less to fiddle overriding theme properties and programmers get 'special' looking buttons. A programmer, who wants a 'red' button, does not care about the theme of the button anyway. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] graphical shapes library or component
On Sat, 04 Mar 2006 10:35:33 +0100, Marc Santhoff <[EMAIL PROTECTED]> wrote: >May I ask which version of the DXF spec you are using? As for the DXF version I have no idea whatsoever. The library is the same you mentioned (John Biddiscombe 1997, based on earlier work from 1995 by someone else). I only used this in a soldering control software project where the PCB drawing were exported as DXF and read to the application using the library. The DXF format was chosen because someone in the company had already started the work using it. It worked, though, and I suppose a revised version is in use in some places even today. All I did was correct some small memory leaks but all my changes are in the final product which is closed source. I have the original library here at home, still and if/when I have the time I will have a look at it (or somebody else, if interested). Markku -- [EMAIL PROTECTED] _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] compile lazarus on opensuse 10.0
On Sat, 4 Mar 2006, John Briggs wrote: > > > Any hint? > > > I have /opt/gnome/lib/libgdk-1.2.so.0 . > > > What am i missing? > > > > Any help on this, please? > > > > Uwe > > Hi Uwe, > For me there are major problems setting up the correct > programming/developement environment in OpenSuSe 10.0. I am currently using > the OpenSuSE10.0 x86_64 distribution and to me this distribution is crippled. > Perhaps you may get the answers to your specific distro questions by asking > them in an OpenSuSE forum. One of my friends, who has little experience on Linux, set up Lazarus on opensuse 10.0 without too much hassle. The distribution is fine and contains all you need, but some names are different from what Lazarus expects. It just takes creating a couple of symbolic links to fix things. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Repository access via the SVN protocol
> >>> > >>> Our german FTP machine was compromised recently (that is why the wiki > >>> is down). The main server has also been compromised some time ago. > >>> Since then, I am reluctant to open too much ports. > >>> > >>> In reality, the problem is with your ISP, namely that they don't > >>> seem to support all WebDAV commands in their proxy. > >> > >> What about letting apache listening to a second port ? > > > > What good would that do ? Fooling the proxy ? > > Yes, mostly transparent proxies are configured for known http ports like > 80, 1080 and 8080 and wont affect other ports. > Hiya Graem Sorry I didn´t respond earlier, I was a bit tied up with getting my new bike registered :) Anyway, just for the record, I have had no problems accessing either http or svn based subversion sites from sentech, so I presume either your own ISP or telkom did something amazingly stupid on their transparent proxy. Of course we do not live in the kind of free market system where if a company buggers up like that they better appologise and fix it before they lose a customer, we live in a ¨internet-consumer¨ system with a single government sanctioned monopoly provider who doesn´t care two hoots about their customers OR their staff (what kind of a company records multiple-bilions in profit and then fires 7000 employees in the same month ? A very unethical one). Oh well, moaning about it won´t fix it, I just wanted to let you know that sentech is coming through clean. Ciao A.J. -- "80% Of a hardware engineer's job is application of the uncertainty principle. 80% of a software engineer's job is pretending this isn't so." A.J. Venter Chief Software Architect OpenLab International http://www.getopenlab.com | +27 82 726 5103 (South Africa) http://www.silentcoder.co.za| +55 118 162 2079 (Brazil) _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] graphical shapes library or component
Am Freitag, den 03.03.2006, 19:45 +0200 schrieb Markku Niskanen: > On Fri, 03 Mar 2006 17:15:05 +0100, Danny Milosavljevic > <[EMAIL PROTECTED]> wrote: > >In gtk terminology that's a "drawing area". A dia canvas is the complex > >thing that *stores* the shapes as objects and such... > > I have been really busy for the past few weeks but I have > now tested the DXF library I used 6-7 years ago in Delphi. > After the LCL corrections with arcs it seems to work now. > It stores the DXF objects as structures of some sort so it > might be of some use. > > For the time being it just reads a DXF file and is capable > of displaying it... and I suppose it can also detect the mouse > movement on the object (I never used this feature). > > If anyone is interested I will mail it gladly. May I ask which version of the DXF spec you are using? In the past I had a lot trouble with DXF, mostly because Autodesk isn't folowing their own definitions. Since Autocad 2000 or 2002 many files from qcad(2) cannot be read by autocad. If it would be possible to read in in the "defective" files and (re)write them again in a proper manner seen from within autocad, I would like to do some testing on it. My last actions with Delphi and DXF were based on the library written by a guy named John Biddiscombe dating from 1997, but I could not get in contact with him. Regards, Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
