Go for it.

the (King)win32 api is dead . No one goes that way anymore. In the apache logs i see something like ie60 .net clr . The next delphi is called .Net not win32(or 64 hehe remember hammer...) It's runing on linux too (sort of) the .net

I seriously doubt that the Window API is dead. Everything .NET will probably use the Windows API (maybe a 64-bit version, but the same basic thing that has existed since the first version of Windows). The .NET CLR is simply a runtime lib for p-code programs. You want Lazarus to be more like Visual Basic? I downloaded a program that used the CLR once and all I can say is that it makes Java seem fast.

_________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

Hi all,

I am new to this Lazarus project.
I have it running under Linux.
CVS update etc. no problem.

But on the Win32 we need some serious win32 interface update. To do this we need �serious� win32 programmers.

I want to spend time at regular base to fix all the bugs. But I if there is a �serious� person who wants to team up with me please let me know.
Send e-mail:

The main problem is of course how many people are really willing to spend free time at regular basis.
Most people are only active and very interested at the beginning of the project and goes back to �passive� user after some time.

It is better to have 2 really active developer than 4 semi-active. Too many semi-active users will slow down the process.

Some discipline that you must have. If you like it or not. Every week minimum 4-8 hours (programming / testing time /etc). Every 2-3 week CVS update.
Prio 1: Win32 interface (update)
Prio 2: LCL bug fix if we find one.

Things to do.
Analyze the problem we have.
- How far are we behind the GTK(2) binding.
- Comparability issue with GTK(2)

Make some plan how to tackle these problems.
Communicate by private e-mail at weekly basis.
Send update as ONE TEAM to Mattias Gaertner? for CVS update.

Project + status + ideas will be save as 1 *.txt file. This file will be including in the win32 interface directory. So other people can keep track of the progress we have. Include are the E-mail address of the active win32 interface developer.

People who want to participate in this project must have dual boot (windows/linux) system.
This is needed to verify the compability issue.
First write a simple program under Linux.
Compile and test it.
Copy this project to windows directory (by mount windows disk to linux). Recompile the test program under Windows and test it And fix the interface problems.

Gerry Ferdinandus.

_________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

This would a MAJOR pain, as wxWindows is entirely C++, which means we would be unable to link it directly with Freepascal 1.0.x, instead all routines would have to be flattened using C, and then linked in. This is the same issue being run into with QT, and very likely why no one has cared to work on the QT port for so long. Also, since the LCL is itself supposed to be an extensive OOP GUI toolkit, basing it on top of another such toolkit makes for ultra-large programs. And really this is unnesesary, as most of the time it would take longer too modify existing code too work exclusively with wxWindows, then too wait until such time as Lazarus is already fully functional, and then, if someone wished too, create an interface designed to use wxWindows, at which time you could hope that C++ linking would be supported by way of FPC 1.2.X. The only reason Lazarus and the LCL, aren't more functional is because of the lack of available time to work on it on the parts of the main developers, switching code mid-gears isn't the solution to this, more skilled programmers willing to devote their time to the project IS.

Andrew

_________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com

"cryst" wrote :

[in addition to the other points made]

... not standard installed with what OS so ever. It doesn't come in standard packages that are on CDs, or can be autoinstalled. Deployment of apps would be a nightmare. (while win32 is standard, and nearly any desktop *nix system has GTK)

It is afaik not in the BSD ports tree, which means it is either not compilable, unusable or not free. (it is free according to its website)

only a hint (maybe is a stupid): if already you want a crossplatform api why don't you choose the .net you could start a port of the ide on that ?

Because .NET is not cross platform. A lot of talk, and a lot of bla, but noone has yet displayed an ordinary Visual .NET app that runs on something else than a recent Windows NT version (not even '98)

There are a lot of

the (King)win32 api is dead .

Microsoft _pronounced_ it dead, but if .NET fails to catch on, that can change any minute.

See Intel, that pronounced x86 dead already 3 times.

In the apache logs i see something like ie60 .net clr .

That is because IE6 has .NET as a new virus procreation subsystem.

The next delphi is called .Net not win32(or 64 hehe remember hammer...)

Only the cmdline compiler is .NET afaik.

It's runing on linux too (sort of) the .net

Not is it not. It has some .NET compiler where Icaza is playing with, but the change that it will ever run a standard .NET windows app is below zero.

There is a pascal compiler for the net :component pascal shure is not perfect but works ...even is spliting out java (my God)

We could build a C# parser into Lazarus. Will you stop using Visual Studio .NET than?

No, because it isn't the real thing :-)

----

Maybe .Net will be usable a bit cross platform, maybe not. But it is that new and unproven that it is still a few years to early for this kind of decisions.

gtk is written in C while the wxWindows is written in C++. Linking a foreign language with C++ libs is _very_ hairy. Mostly, you need C wrappers as Borland did with Qt too. If the C++ interface isn't so "clean" as the Qt ones is, it is almost impossible to link foreign languages with C++. Even between different versions
of one C++ compiler this applies! Exceptions, multiple inheritance and templates and the name mangling make the story so difficult.

Qt 3.0/KDE3 shouldn't be a problem, I started already with the conversion using a
hacked kalyptus which outputs pascal instead of C.

only a hint (maybe is a stupid):
if already you want a crossplatform api why don't you choose the .net you could start a port of the ide on that ?
the (King)win32 api is dead . No one goes that way anymore. In the apache logs i see something like ie60 .net clr . The next delphi is called .Net not win32(or 64 hehe remember hammer...) It's runing on linux too (sort of) the .net
There is a pascal compiler for the net :component pascal shure is not perfect but works ...even is spliting out java (my God)

I spent some time trying to get the win version to compile. After a frustrating week I gave up. (My time is also limited as well so my contributions wouldn't have been too great anyway). �
I've been thinking over the last few months of a
way to greatly increase the scope of Lazarus.� When I first joined this mailing list, it was because there was no such animal as Kylix and I greatly desired the ability to compile the same code on Windows and linux and use Delphi (or something like it) to do it.� To me if I just wanted to code in Windows I'd use native windows tools... If I wanted to code in Linux I'd use native Linux tools. The strength that Lazarus can have is in it's abiltity to be able to compile in both environments.
�
To do this, originally the GTK API was to be the
interface to the Gui. This works with the gimp so I could see no reason for it not to work with Lazuras. Turns out it's harder then it looks (apparently).� My suggestion is that the whole group code towards wxWindows. This api was created specifically to allow different OS's to run the same interface code. If the whole group had wxWindows at the same level that Lazarus is at with gtk then windows support, (and Mac and others as well) would already be present. The wxWindows is Open source and could use�a nice programming environment (like Lazarus) to support it. �
What do you think?
�
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

you wrote

Send update as ONE TEAM to Mattias Gaertner? for CVS update.

I think if Martin knows that you work seriously you'll get cvs write access as well.
It makes the work for you and Martin easier :)

Just as a side note, I've some win32 header translations lying around that might be useful.

(Commctrl and shellapi)

Hello

I'm interested to help with the Win32 part also. Luciano, did you find out something
about the Win32 interface already?

Markus

Thanks, Michael. I'm going to ask some questions, and I think it's preferrable to do that on the list, because not all of my questions are exclusively on Win32 implementation and so other can help.

cryst wrote

The LCL seems to be having problems getting traction as a cross O/S toolkit. wxWindows is there and working. We just need to interface to it.

The LCL was designed exactly for this purpose. To allow you to write different interfaces to different API's. Anyone is welcome to start work on a wxWindows API.

I don't believe this means a total scrap and rebuild, but rather the low level O/S calls go to the wxWindows wrapper functions which sort out the details

This is exactly what the API independent interface does. Just write the appropriate calls to wxWindows.

(which is done at the wxwindows compile time with conditional compiles). So the overhead isn't anymore then we would have to go through anyways.

Well that isn't exactly correct. In the standard use of wxWindows you would be using the wxWindows objects when coding. In other words you would just supply call back links to procedures for events, etc. etc.

However, when using Lazarus it has it's own event driven architecture. This LCL event code in turn talks to the wxWindows event code. So while the widget set independence is possible in the LCL design it isn't exactly a walk in the park to get it to work. :-)

This is the reason that the Win32 API interface isn't totally working yet. :-)

My suggestion is that since Lazarus seems to be heading towards direct O/S api interfacing anyway,

What leads you to believe this????

I don't know that more programmers will help this or not. In my experience 5 programmers is a good team size.

You don't seem to understand. There AREN'T even 5 programmers. At this point there are only 2-3 programmers with available time at the moment to work on Lazarus. There was only 1 working on the Win32 API and I don't believe he has been available much in the last couple of months.

So we don't have a tooo many cooks issue we have a NO BROTH issue. :-)

Thanks.

It is true that Delphi and Kylix is the best Pascal IDE at this moment. I use Delphi6 Pro. at my work.
By using delphi CLX library I can write simple delphi program on windows and recompile it on kylix.
It is frustrating to �downgrade� to Lazarus for writing application. I can not recommend it to anyone for writing application at this moment. Lazarus is still in beta stage. With lots of bugs. Unstable etc. But the whole point is how we as object pascal programmer can help Lazarus to develop to a more mature product.

www.WxWindows.org look promising.
I will install it on my windows PC and call this toolkit from Delphi6. Need some header conversion to do.

I will keep you inform.

_________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

Thanks for correcting me. I see your point(s) and won't push this any further. (further comments within).

This is the reason that the Win32 API interface isn't totally working yet. :-) > My suggestion is that since Lazarus seems to be heading towards direct

O/S

> api interfacing anyway, What leads you to believe this????

It appears that Lazarus has three main thrusts Linux, windows and bsd (the poll on the site). There is a win32 api interface, and gtk seems to be for Linux. (I don't know about bsd). The gtk as you said is always behind in windows, and I assumed that it been quietly dropped in favor of the win32 interface. (Bad assumption on my part).

> I don't know that more programmers will help this or not. In my

experience 5

I'm truly sorry to hear that. I was under the impression there were about 7 programmers working on it. I wish I had the time to spend on it myself as I think it is a worth while project. As I said I tried to get the win32 api working but it looked like code was missing and it wouldn't compile. I then got busy and wasn't able to go any further with it. Well maybe I can try again in a month or so.

cryst wrote

My suggestion is that the whole group code towards wxWindows.

As was stated there is no reason why someone can't develop and LCL interface to wxWindows, but as to it being the best choice, I can't agree.

What the LCL interface code does is create a direct link between the widget API and the LCL objects. In our case we started with GTK since, as was also mentioned, it isn't written using C++ objects.

Now as you point out wxWindows gives you a cross platform capability when coding. But it does this by using a generic interface between your code and the widget API. This is exactly the same thing that the LCL interface is doing. So if you look at the Unix/Linux versions of wxWindows it uses GTK or Motif to provide the GUI widgets.

This would mean we would be writing a generic independent set of objects in the LCL, that would talk to an interface written to communicate with wxWindows, which then in turn talks to an interface which talks to GTK.

That is adding a WHOLE lote of extra interface for no additional benefit.

I think one thing that has to be made clear at this point is that it isn't the capabilities of the Lazarus LCL that are being worked on. For the most part what is being worked on now is the IDE itself. The interface between the LCL and GTK is fairly complete and stable. In fact the very fact that the IDE operates as it does is a testiment to the completeness of the LCL/GTK interface. The IDE or any IDE for that matter is a very complex and involved application.

The Windows verions of Lazarus using the Win32/GTK would work better if it could use the latest set of GTK libraries. However, given the fact that the Win32/GTK libraries are usually behind in development of the Unix set it never seems to be as stable. When a 2.0 version of Win32/GTK is finally available we might see more stability and a closer compatibility between Linux GTK and Windows GTK.

As an alternative to Win32/GTK a direct Win32 API interface is being worked on. This means that it would be more stable and written directly for Windows. However, this needs developers to help with this effort.

You are right. :-)
Limited CVS access to win32 interface module is a better way to do this thing.

But first I want to see if I can team up some win32 programmer so I can start some private discussions about the problem we are facing now. The priority etc.

So I will wait for �private� E-mail response.

In the mean time I will proceed with the �study� of the win32 and GTK interface.
Maybe this effort will fail.
But time will tell.

Gerry Ferdinandus

_________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

On Tue, 27 Aug 2002 10:36:16 -0400 "cryst" wrote : >If the whole group had wxWindows at the same level that Lazarus is at

with

would

be unable to link it directly with Freepascal 1.0.x, instead all routines would have to be flattened using C, and then linked in.

I don't see how this is different the gtk.

This is the same issue being run into with QT, and very likely why no one has cared to work on the QT port for so long.

I wouldn't know about that.

Also, since the LCL is itself supposed to be an

extensive OOP GUI toolkit, basing it on top of another such toolkit makes for ultra-large programs.

The LCL seems to be having problems getting traction as a cross O/S toolkit. wxWindows is there and working. We just need to interface to it. I don't believe this means a total scrap and rebuild, but rather the low level O/S calls go to the wxWindows wrapper functions which sort out the details (which is done at the wxwindows compile time with conditional compiles). So the overhead isn't anymore then we would have to go through anyways.

And really this is unnesesary, as most of the time

it would take longer too modify existing code too work exclusively with wxWindows, then too wait until such time as Lazarus is already fully functional, and then, if someone wished too, create an interface designed

to

use wxWindows, at which time you could hope that C++ linking would be supported by way of FPC 1.2.X.

My suggestion is that since Lazarus seems to be heading towards direct O/S api interfacing anyway, why not adopt one instead of trying to code every O/S out there. Of course you probably have more experience in this then me, as I'm a bystander at this point.

The only reason Lazarus and the LCL, aren't

more functional is because of the lack of available time to work on it on the parts of the main developers, switching code mid-gears isn't the solution to this, more skilled programmers willing to devote their time to the project IS.

I don't know that more programmers will help this or not. In my experience 5 programmers is a good team size. Too many cooks can spoil the broth and all that. Time on the otherhand I agree is the greatest problem. If there were 40 hrs to the day I would have enough :) So my suggestion wasn't intended to burden you or the group down with more things to do, but to narrow the focus to one api, which covers multiple operating systems, thus leveraging your time.

Chris

?? You mean an ordinary file here or, for instance, a delfhi form ?

Lazarus resources aren't added to the executable by the compiler (or is it linker ?) like windows.

The "trick" we used is that "resources" are included in the initialization part of a unit. This include contains one ore more calls to store the resource name, type and data in an own global resource list called LazarusResources. When reading from resources, the data is read from this list.

The only difference in this approach is that you can't edit them externally like on windows platforms.

I haven't found the file classchart.ps. Is it on fpc cvs tree? When am I stopping asking such a lot of questions?

I don't know :-)

Marc

Hello.

It seems to me I'm not getting all of messages directed to the group. My own message didn't arrived here. I've tried to check the miraclec archive, but all I've had was a 404 error.

You are confusing Objects with Classes. LCL uses classes, not objects.

You're right. I didn't pay attention. Sorry. It's good to have objects streaming encapsulated too.

Is it implemented in such a way that a file written by an application compiled by Delphi would be readable by an application compiled by FPC?

Note that FPC does not yet support resources on all platforms, which makes it necessary for Lazarus to use some tricks to be able to store and

restore

forms from "resources".

I've been reading about that, mainly about string resources. But, what about binary resources? What was the decision taken by the Lazarus team to solve that? What are that tricks?
I haven't found the file classchart.ps. Is it on fpc cvs tree? When am I stopping asking such a lot of questions?

Luciano.

The FPC docs sources contain a .ps file called classchart.ps containing a very outdated class chart. It's coded
plain but it should be easy to understand.

Example:

newcolumn
(TComponent) Ready newlargeheadclass
(TDatabase) Untested newchildclass
(TDataset) Ready newclass
(TDBdatset) Untested newchildclass
onelevelback
(TField) Ready newclass
(TBooleanField) Ready newchildclass
(TBinaryField) Ready newclass
(TBytesField) Ready newchildclass
(TVarBytesField) Ready newchildclass
onelevelback
onelevelback
(TBlobField) Ready newclass
(TGraphicsField) Ready newchildclass
(TMemoField) Ready newclass
onelevelback
(TDateTimeField) Ready newclass
(TDateField) Ready newchildclass
(TTimeField) Ready newclass
onelevelback
(TNumericField) Ready newclass
(TBCDField) Ready newchildclass
(TFloatField) Ready newclass
(TLongintField) Ready newclass
(TAutoIncField) Ready newchildclass
onelevelback
(TSmallIntField) Ready newclass
(TWordField) Ready newclass
onelevelback
(TStringField) Ready newclass

I've been lurking on the mailing list for some time, and I'd like to throw in my $0.02 here.

The Win32 API is far from dead. Several projects, including Wine and ReactOS are alive and very well, which will continue the use of this archetecture for many years if not decades to come (I'm still tripping across PDP-11 emulators every once in a while). Although I would agree that Microsoft is leaning away from the Win32 API, it is still a primary platform even for Microsoft and its developers.

As an interesting side note, there is a series of servers that HP is currently releasing with FreeDOS installed as the primary OS. I guess the assumption is that you can choose to install your favorite version of Linux or whatever OS you want after it arrives on your doorstep.

I am currently doing some very serious development work using the Win32 API right now, and it will be interesting to see how much dependancy the dotNET archetecture is going to have on it as well. In fact, from most of what I've seen from current developers using dotNET, they are very heavy with the use of Win32 API in their code (unless you are using Mono, but that is still another story). The Win32 API is accessed through a Windows API class archetecture, and encapsulated in some dotNET objects, but it is still the same old Win32 API that I've been using for about the past 8 to 10 years. You just use an object rather than the DLL functions directly.

As far as dotNet support for Free Pascal and Lazarus, this is something that should be built directly into the compiler (as far as the p-code is concerned), with the LCL classes being translated somewhat to the dotNET class archetecture. In fact, the dotNET class structure is much more friendly to the TObject single inheritance model common with Object Pascal than to the multiple inheritance models that are found in C++ or other languages. The execution speed is a commonly debated item among hardcore Windows developers, but you must remember that there is a "compiler" that translates the "p-code" into direct machine instructions in a typical dotNET environment, which will give roughly comparable speed to a similar program written in C++ in Windows. My own experience is that the speed is about 95% to 98% of the speed of a native Win32 app. There is a penalty, but not as much as you would think. This "compiled target machine code" is stored on the hard drive, so I would expect that the need for 200 GB hard drives is going to be critical in the near future for Windows, unfortunately. I also see dotNET as Microsoft's ticket to move to a 64 bit archetecture (the code doesn't even need to be recompiled...well at least into p-code). I would say it is more of a case of Microsoft trying to push Intel away from being the major supplier of MS-OS computer systems.

The real key to look for from Microsoft as to the direction they are really going is to look at what they are using to develop their current version of MS-Office. That code is almost exclusively Win32 API, with COM and COM+.

The number one thing that I hear from developers using dotNET right now is that they finally got the GUI working correctly for the IDE in Visual Studio dotNET. They borrowed heavily from the Delphi IDE, but kept the flavor of Visual Studio for the diehards. Unfortunately you have to learn C# (or D-flat as some co-worker call it). At least if you stick with Visual Studio. That shouldn't always be assumed (especially considering Borland's moves to have Delphi compile to dotNET CLI).

Robert Horning

Thanks for the correction. The point I was trying to make is that you need to be careful when you write off an OS or platform. Apple Computer effectively killed off the Apple ][ platform when it was still making quite a bit of money, and there are still Apple ][ emulators floating around. Even Atari 2600 emulators (for the true diehards of 8-bit computers.) I have even heard about some places that are still manufacturing Comodore 64 computers (eastern europe?), mainly because you can get the OS and archetecture for practically nothing, and it is fully debuged and tested... the design and code base that is. And the Amiga seems to keep trying to rising from the dead, although I think its death is now complete.

It will be a long tortortus death for the Win32 API, if for no other reason than so much software has been written for it that it will continue to rise from the dead if for no other reason than to play Quake or Doom.

Robert Horning

As an interesting side note, there is a series of servers that HP is currently releasing with FreeDOS installed as the primary OS.

Actually it is Dell, and they are enterprise workstations. (Optiplex)

I guess the assumption is that you can choose to install your favorite version of Linux or whatever OS you want after it arrives on your doorstep.

Hardly. It is more avoiding double Microsoft tax (large companies already bought large amounts of windows licenses for imaging. They don't use the added licenses. We have two 21 inch monitorboxes in the basement full with Dell and Compaq OEM Windows 98 licenses. (ok, one is 2/3 full)

You are confusing Objects with Classes. LCL uses classes, not objects.

The FPC classes streaming system is implemented to be compatible with Delphi's. It has been implemented in such a way to make it extendible (e.g. storing forms as XML would be nice)
However, at the moment, there is no other implementation then the text streaming or binary streaming as implemented in Delphi.

Note that FPC does not yet support resources on all platforms, which makes it necessary for Lazarus to use some tricks to be able to store and restore forms from "resources".

Michael.

Luciano Coutinho Barcellos wrote

1) Is there any diagram documenting the LCL classes and their hierarchy?

There is one, which might be old, that shows the FCL upon which the LCL is built. I have never managed to find the time to add the LCL components to it.

http://www.freepascal.org/fcl/classchart.gif

2) Is there any compromise with Delphi/Kylix VCL compatibility?

At this point things have been developed with Delphi 5 in mind.

3) I've been studying the FPC ...

I leave this for others to answer.

4) Is the only issue work on the visual components?

Lazarus is only about the visual components or the VCL portion of Delphi. The underlying portion that isn't visual components is handled by the FCL which is in the hands of the FPC developers.

You can of course add to the FCL but that is done along with the FPC team and not handled via the Lazarus project.

5) Does the Lazarus IDE itself use the LCL?

Of course. All of Lazarus is built with FPC and the LCL.

So, will having the LCL running on Win32 imply on having the Lazarus running on Win32?

That is correct. The IDE is built calling functions and procedures and objects in the LCL and has no ties directly to the OS or widget set. Once and interface is written on a given platform the IDE should work, That is of course assuming that all of the required interface features are available. :-)

6) Have anyone heard about the book Design Patterns,....

I have not and thus all the original design of the LCL aren't based on whatever it says. :-)

7) Can I keep sending HTML messages to the forum? :-)

We would prefer that you didn't.

Your diagram doesn't convey the nature of the LCL design or layout. I will work on making a block diagram that represents the design. I'll work that up later tonight and post it on the web site.

It is not SO outdated ! :-)
90% of the FCL is in it, as far as I know :-)
However, I will see about getting it up to date again. I was busy documenting anyway.

Michael.

Luciano Coutinho Barcellos wrote

I've tried to check the miraclec archive, but all I've had was a 404 error.

OUCH. Nobody noticed this bug until now???? :-\

I forgot to change the link at the bottom of the emails when the new web site went online. For now please go the web site to get access to the archives.

But the lazarus part is outdated!

It appears that Lazarus has three main thrusts Linux, windows and bsd (the poll on the site). There is a win32 api interface, and gtk seems to be for Linux. (I don't know about bsd).

BSD is in nearly everything 99.9% like Linux. Linux partly inherited from BSD (see various manpages), and both lean heavily on GNU.

Most of nearly all differences needed are in the command names for the build process, not in the actual code. (e.g.

- GNU make, that Linux packages as default is called "gmake" under *BSD,

- bash is not mandatory in /bin and symlinked to /bin/sh, but in /usr/local/bin, and /bin/sh is a the original bourne shell. #!/usr/bin/env bash is the good way to start a script. Half of the scripts would run with sh anyways.

- Most programs should install to /usr/local, since /usr/* is generally considered off limits

- libgcc isn't autolinked, and needs sometimes an explicit addition. )

A nice example are the GTK2 headers on sourceforge. Didn't change a single letter sourcecode, but had to patch all compile scripts, and fiddle a bit with the link options to get it running.

Hello, Markus and
everybody.��� Well, I wish�to use my free time to work on Lazarus. The fact is there was no "free time" for me during the last weeks. That is going to change next week.�I would like to start working then.
��� But, as I see a lot of messages
about the subject I would like to ask some questions to speed up my learning about how LCL is organized. I must say I don't have a�lot of experience�under FPC or even, under Unix yet, altough my computer being a dual boot machine since a long time ago, and I have a large experience on Win32 programming with Delphi or Visual C++. So some questions may be about the FPC itself:
��� ��� 1) Is there
any diagram documenting the LCL classes and their hierarchy? ��� ��� 2) Is there
any compromise with Delphi/Kylix VCL compatibility? ��� ��� 3) I've been
studying the FPC sources and docs,�and the object streaming system seemed to be different from Delphi. Is that true, or Lazarus/FPC is already capable of storing every published property? For every object should I declare a Load constructor and Store method and then call RegisterType (from objects Unit)?
��� ��� 4) Is the
only issue�work on the visual components?
��� ��� 5) Does the
Lazarus IDE itself use the LCL? So, will having the LCL running on Win32 imply on having the Lazarus running on Win32?
��� ��� 6) Have
anyone heard about the book Design Patterns, from Addison Wesley publishing? Is any concept mentioned there being used on Lazarus design? ��� ��� 7) Can I keep
sending HTML messages to the forum? :-)
��� Well, that's all, for now.
Thanks.
�
��� Luciano.
�
�<IMG alt="" hspace=0
src="gif00000.gif" align=baseline
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gif00000.gif
Type: application/octet-stream
Size: 7032 bytes
Desc: "border=0>"
Url : http://localhost/pipermail/lazarus/attachments/20020827/1e66e7d5/gif00000.obj

A nice example are the GTK2 headers on sourceforge. Didn't change a single letter sourcecode, but had to patch all compile scripts, and fiddle a bit with the link options to get it running.

Can you send them to me, so that I can put them in cvs?

Mattias