G'day all,
I have had this problem for a while and wonder if anyone else experiences it. I'm running Debian Woody, and latest CVS 1.0.7 and CVS Lazarus.

I can't build Lazarus smartlinked.
If I try to build it with smartlinking enabled in my fpc.cfg file, it gets to linking point and ld consumes all available memory, then the kernel terminates the process. Static linking works ok, except that a basic hello world compiles to 700kb.

Is anyone else compiling smartlinked?

Brad

Some time ago there was a discussion about the client area in the win32 interface [I lost the thread].
If i'm not wrong, the problem is that is smaller than the gtk interface where the clientarea = windowarea,
so i tried to work on it.
The results are attached.
With these modifications the TForm.Width property sets the ClientWidth and not the WindowWidth.
Note that it is not the Delphi behavior!

The way i done it's not the best (and it's not complete: it would check the presence of menu and the style).
I think better approach is to implement the
InterfaceObject.AdjustWindowRect function
for calculate the proper window size _before_ send the LM_SETSIZE message. And later implement the ClientHeight,ClientWidth as in Delphi.

By the way, is there anyone currently working with the win32 interface? There was a try to make a group some threads ago.
I'd like to contact. Maybe i can help.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00001.zip
Type: application/octet-stream
Size: 1297 bytes
Desc: "win32int-diff.zip"
Url : http://localhost/pipermail/lazarus/attachments/20020915/8cb09627/zip00001.obj

Gerry Ferdinandus wrote

Thank you for showing interest in win32 interface.

My comments are a follow up to the comments from Mattias.

I have to agree with Mattias. This approach might have worked about three years ago when we started but with the current complexity and interrelationship of the code it is unlikely to work well.

At this moment there are no win32 team group. You can send E-Mail directly to me for offline 'work' discussions. And team up with me?

It is great if you can put together a team of developers to work on the Win32 interface but we would rather you stay involved with the developers as a whole. We have another mailing list which is used just by the core developers. If you do get a team together and start doing work and want to commit changes to the project we will include you in this list and give you access to CVS. If required, I can also setup another win32 developer specific mailing list but please try to keep your conversations include with the rest of the developers so that we can all play a part.

Some of us (such as myself) have been working on this project now for over 3 1/2 years so we have a pretty good idea of the problems and pitfalls. :-)

As Mattias mentioned, the LCL is a work alike. We decided a LONG time ago that the LCL would work like the VCL and be very, very, very similar but would never be able to totally port Delphi code. At that time Kylix didn't even exist so no plans for CLX intergration was even possible. Lazarus is not suppose to be a Delphi clone. It is a Delphi work alike. It will/is able to import existing DFM files and standard non-component code with little changes. However, anything component specific is expected to require some tweeking.

We are trying to design the LCL to use the best capabilities that the API has to offer. Just because the VCL does it one way doesn't necessary mean that it is the best way. :-)

That being said if there is something you guys find that would work better if the GTK interface changed then by all means lets do that. That is the reason why it is best if all developers are talking together on the same mailing list.

And above all, have fun working on it. :-)

Hi Karl,

Thank you for showing interest in win32 interface.

I am studying the win32 interface code to see what is the best approach to finish the job.
The best approach is I thing to finish it at �message� level one by one. For example:
Finish LM_CREATE for all components + testing.
Finish LM_DESTROY for all components + testing.
Finish LM_SHOWHIDE for all components + testing.
Etc.

And not �jumping� from one bug fix to another bug fix. With this approach is too difficult to organize the �work�. And there is the possibility of to much method/event that�s not implemented with the above �jumping� approach.

At this moment there are no win32 team group.
You can send E-Mail directly to me for offline �work� discussions. And team up with me?

3 Potential Windows32 interface programmer:
Markus L�din E-Mail:
Karl Brandt E-mail:
Gerry Ferdinandus E-mail:

Gerry FErdinandus

Ps.
Karl,
I personally think that LCL + (GTK/Win32) interface should have the same behaviour as VCL and/or CLX.
This is to avoid long discussions.
If the GTK interface is not VCL/CLX compatible then the GTK team should fix it if possible.

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

For the win32 interface this might be possible. Although I doubt it. There are too many dependencies. You can't program one part completely and fully test it without the other parts. Especially because the LCL is not complete and like every other gui will never be.

If you are really interested, then you should probably be added to the devel list.

This sounds a bit as if the LCL should merely become a VCL emulator. The primary goal of the LCL is OS independency and the second is VCL compatibility to use Delphi components. The win32 specific parts of the VCL will probably be different, although very similar. And of course the gtk programmers want to have some of the gtk features like themes and multiple clipboards. I don't know what special abilities Aqua, WxWindows or QT have, but I'm sure, when they are implemented we will see some new things in the LCL.

Mattias

Shane Miller wrote

Michael, it's only been 3 1/2 years? It seems longer. :-) Shane

Heee heee.

I had to check some of my old files and emails to figure it out myself.

I agree that these emails (win32 related) should be on our developers mailing. If possible, when you are creating them, add [win32] to the subject just like the [lazarus] appears here. It'll help those on the development list that are not interested in the win32 stuff to sort through the emails.

Michael, it's only been 3 1/2 years? It seems longer. :-) Shane

Windows 32 interface is a long time project. So we need some �project management method� implemented here.

a) To make this project success full we need some good documentation. Like what is implemented at message level and things still need to be done etc. So we need some agreement about the document structure and the contents. People come and go. But documentation stays. If will also help other potential windows interface programmer.

b) Testing tools.
For testing our interface we need some testing programs. The Lazarus examples are not suitable for our purpose. So we need some new one. For example one program to test ALL the property and event of Tbutton. An other program to test TComboBox etc. The new examples will also benefit for the future �new� interface project (native OS X interface?). This is a �long term investment� for the Lazarus project. But we need these testing tools.
You need to test these new examples first on Linux/GTK system. (Dual boot system is recommended working method). Because LCL+GTK is �stable� for programming and testing purpose.

c) Win API knowledge.
I thing most Delphi programmers does not know much about win 32 API. Of show no interests in studying it. Because they are trained in programming with component. This can be a problem for our goal. But for point (b) you do not need to know the API. For point (a) Api knowledge is recommended. I have a book �Programming windows 95� by Charles Petzold (1996) it�s about programming windows with visual C by using API and not MFC. This is where I get my info about API.

As you can see �hacking� the Windows32 interface code now is not professional for the long-term investment. So we must decide first if we want to �hacking� now or follow the above procedure. First thing we must know our limitation in both time and knowledge of the subject. And do not get over excited about things.

I think the testing tools are the most important things for now. So I suggest that we write ALL the testing tools and THEN make the decision if we want start �hacking� or start documenting (a).

I do not know. I am not on the win32 developer mailing list. (PS. For windows32 related post use [win32] in the subject)

I do not know if he is still interested in windows interface. Maybe he can answer it for him self.

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

Which target? Assuming win32.

The check is done on the existance of "pwd" or pwd.exe.

For win32, it seems to be in my c:\pp\bin\win32 directory, on Unix it is standard.

Is your path variable set up correctly? And is the FPC directory named before the cygwin one in your PATH?

What kind of tools are thinking of. Something like a unittesting tool as DUnit. If you could be a bit more specific, I could maybe help and write those tools.

So do I.

The tools are in the makew32.zip package. It checks if it can find 'pwd.exe' in the PATH. If not then it gives this error. Also all files should be lowercase since the wildcard match in make is case sensitive.

Hi,

I'd like to build the lazarus IDE from a snapshot I downloaded, but I get the following error when I do a make:

"You need the GNU utils package to use this Makefile"

What in heavens name is the GNU utils package. I
downloaded the latest fpc 1.0.6 completely, and did a full install. Furthermore, I downloaded and installed some GNU file utilities from a freepascal ftp mirror site - I assume this is what is meant by "GNU utils package".

Any pointers on what to do next ? From what I read in the mailing list archives, I must be the only one not succeeding in doing a make. The error message is
frustratingly unclear to me.

Tia,

Joris Spriet
a pascal/Delphi enthousiast.

__________________________________________________ Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

Great !
The 'lowercase' thing solved it; I had mixed case
pathnames. However, now I'm getting the following message:
lazarus.pp(84,1) Error: resource compiler not found, switching to external mode
lazarus.pp(84,1) Fatal: There were 1 errors compiling module, stopping
Closing script .\ppas.bat
make[1]: *** [lazarus.exe] Error 1
make[1]: Leaving directory
`C:/Projects/FreePascal/lazarus/lazarus'
make: *** [ide] Error 2

I've got a program windres.exe in /pp/bin/win32 (which is in my path) ...
What it is looking for ? Do I need to configure a compiler setting ?

Thanks for your time.

Joris Spriet

__________________________________________________ Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

Thanks for the reply.
I agree with you, at least partially.
To make such a beast as a GUI interface,there must be discipline, but at some point of development will appear
one or other bug that must be defeated before we can proceed.

What I think it must be done is contact who is interested in develop the win32 interface,
make a list of priorities,
and then define tasks for which one, so would not have duplicate work and would be more or less organized.

At this moment there are no win32 team group. You can send E-Mail directly to me for offline �work� discussions. And team up with me?

I think the best place to discuss is in the maillist. Are there some discussion about win32 in the developer maillist?

How about keith bowes?

Karl Brandt

Shouldn't the TEdit control include an OnKeyPress event?

I was looking at the source for the TComboBox and can't figure out how it's implemented... I don't see any actual code for it, just the property definition.

Is it a GTK problem?

Thanks,
Tony

Gerry Ferdinandus wrote

I think one doc with this type of table should be enough. Every component will have it own table. It is going to be a big document.

Just FYI. We attempted this very thing at the beginning of this project. It didn't developers did work on the components and features they failed to report what exactly it was that they worked on and what the status was. It ended up being thrown out because it was never accurate as to the state of the project. :-\

I'm in a rush due to the storms slung off the hurricane, so I only posted the binaries and required graphics.

The source will follow later when I get it cleaned up.

http://tony.maro.net/mod.php?mod=userpage&page_id=21

Fully functional checkbook balancer with a feel like Microsoft Money.

Very few range checks occur yet, so don't be surprised when it crashes after you put in an invalid date field or such... But, I need to know if it just flat won't run on someone's computer or the like. Or, if you go to import your QIF file and it croaks... or whatever. Drop me a line if you see something freaky happen - I may already know about it, but that's okay.

Things went fast after I quit having to fix my form files by hand every 20 minutes from the corruption! LOL

Play with it and see what you think... I've still got a long way to go to be able to quit using Microsoft Money, but much of the functionality is already built in and just not implemented in the UI yet. I don't expect the file format to change, and if it does I've written it flexible so it should still open older versions. I'd hesitate to suggest anyone use this as their only financial software yet... there may be some huge bug somewhere.

Not bad for just over 2 weeks work...

-Tony

The best approach, i think, is have on mind one objective and go in this way.
As you said lazarus/win32 is a big task, and we can't take as primary objective make it complete,
so i propose to divide the work in tree steps/objectives:

Make the win32 interface:

1) USABLE
Where the principals properties/events/methods of the principals components work.
2) USEFUL
Where more components, properties/events/methods works {Note that only recently lazarus/gtk got this state}
3) COMPLETE
Description not necessary

Once we believe in this way, we must elect the
components/properties/events/methods that are necessary to which step and make the docs with these.
Basically i propose two types of doc (if we agree that it must exist): One summary table with the state (3 or 4) of the property/event/method One doc with one detailed table for which control.

At the moment i don't think that all properties must be tested (see above), only the most common.

Fundamental

As you can see �hacking� the Windows32 interface code now is not professional for the long-term investment.

The lazarus project can't be thinked as professional because it relies on voluntary help ;-)

So we must decide first if we want to �hacking� now or follow the above procedure.

For now let's see what other people think

First thing we must know our limitation in both time and knowledge of the subject. And do not get over excited about things.

Correct. We also have life

AFAIK he is the win32 mantainer.

Agree, the project will be divided is 3 project milestones: USABLE, USEFUL And COMPLETE.
So every properties/events/methods can have 3 �priority level� Document table based is ok.
Some table idea:
The �X� mark the �priority level�
When finish/tested the finish column will be �X� TButton | USABLE | USEFUL | COMPLETE | Finish --------------------------------------------------------------------- OnClick | X | | |
Caption | X | | |
Font | | | X |
Etc.

I think one doc with this type of table should be enough. Every component will have it own table. It is going to be a big document.

Here is some extra explanation about the testing tools.
1) We must use EXACTLY the same testing tools. This is to avoid problems like. Tbutton 'testing' works fine on your computer. But does not work on my computer. Because I am using different testing tools etc. This will cause unnecessary frustration under team members.

2) Type and quality of the testing tools. This can be a long debate. Complete testing of all properties/events is NOT needed at this moment, only the most common. You are right about this. At this moment I am experimenting with a simple TButton �testing tools�. It is edited/run(F9) under Delphi6 and can also be compiled with MAKE(fpc). This way I can use VCL as reference how it should work. And still be able to compile for LCL. I do not know if this is the best way to do it. For editing pascal code I always use Delphi.

(Same working methods and tools for all team member is recommended. This is to create better understanding for each other work and it is easier to help each other when problem arise.)

That�s true. But there is not much volunteers right now. ;-)

Yes, he is. But nobody is helping him. :-(

PS.
(Message for "Vincent Snijders" )
I have read you e-mail. Thank you for your help (writing the test tools). But at his moment we must first decide our working methods. We will keep you inform about the progress.

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

I made a sample table that ilustrate what i said.[see Attachment] The colors indicate in what objective/step the property is. red -> usable
yellow->useful
green->complete
For example:
The property Height is red so it's a property that must be working to get the usable target.
This way, we must concentrate our efforts to get all red properties/events/methods Done before jump to the yellow ones ... I propose three flags: Done, Partial, Broken
The fields Details, Devs, Extra don't need explanations I see this as a good way to organize the job, make-it produtive, and avoid duplicate work ;-)
But requires some work :-(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00003.zip
Type: application/octet-stream
Size: 979 bytes
Desc: "lazwin.zip"
Url : http://localhost/pipermail/lazarus/attachments/20020924/2e542672/zip00003.obj

Making a document with things to do seems like a good idea. Certainly if the work can be divided with it.

Maybe we could be it more useful if we change it a bit. At the momennt it looks at the interface of the LCL (properties, methods and events). I think we should look at the interface of the win32Interface object. We should try to make that compatible with the gtk interface object.

Therefore I propose a different setup, in which we document which messages are sent by the LCL to the interface object en what messages the interface the interface is supposed to send to the LCL.

It could be used for future porting as well, as it gives a description of what has to be implemented by an interface.

Vincent Snijders