Yea man I really need that winproc now to move forward.

Cliff

I would prefer that we add a LINUX.PP file to the LCL and create new functions with these ssame names. That way we don't have to change ANY code except the USES clause. In the USES we would just have to add linux.pp and the winapi calls would be there.

Shane

>> Curtis White 10/26/99 11:36PM >>>

I agree with you. I like the last option. But the problem we will need to overcome is the compatibility with Delphi. Almost every Delphi unit in existance contains:

uses Windows ...

So all of those would need to be changed depending on which environment you are compiling in. If compiling in Windows, then everything is fine. But then the code will need to be changed to compile in Linux. Also, when compiling in Windows, how would we handle functions that are the same in both LCLwindows and Windows?

Curtis

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

I agree with you. I like the last option. But the problem we will need to overcome is the compatibility with Delphi. Almost every Delphi unit in existance contains:

uses Windows ...

So all of those would need to be changed depending on which environment you are compiling in. If compiling in Windows, then everything is fine. But then the code will need to be changed to compile in Linux. Also, when compiling in Windows, how would we handle functions that are the same in both LCLwindows and Windows?

Curtis

Marc Weustink wrote

System: StringOfChar

Implemented will apear in cvs soon.

Michael, can you document it please?

I would love to get the menu's worked out correctly.

Otherwise, I am writing the WNDPROC for TCONTROL, WINCONTROL, and CUSTOMFORM. Feel free to write any others...

Shane

>> Marc Weustink 10/26/99 12:38PM >>>

Hi,
As you might have noticed, I'm back from my holliday trip. After reading loads of email, I'm wondering what to do. The last thing I did was on the notebook, and after that I would have looked at the scrollbar. If I recall it correct, I read somewhere that Cliff continued this.
Further, I read something about the editor. It looks to me if the mwEdit is almost tackled, so need any help there ?
Otherwise, maybe I can look after the (now IMHO incorrect mixed) use of parent and owners, which also touches some curent changes in the menu (getting both straight).

Greetings Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Anyone else having trouble compiling due to the error in thread.inc? Anyone working on this?

I just fixed it, if not you should wait until i'm home again.

Peter

OK, instead lets use a LCLLinux or LCLWin file. Either or, but not both, and put all the winapi stuff in there. I'll rename my LINUX.PP file to one of those. Any preferences?

Shane

>> "Shane Miller" 10/27/99 06:49AM >>>

I would prefer that we add a LINUX.PP file to the LCL and create new functions with these ssame names. That way we don't have to change ANY code except the USES clause. In the USES we would just have to add linux.pp and the winapi calls would be there.

Shane

>> Curtis White 10/26/99 11:36PM >>>

I agree with you. I like the last option. But the problem we will need to overcome is the compatibility with Delphi. Almost every Delphi unit in existance contains:

uses Windows ...

So all of those would need to be changed depending on which environment you are compiling in. If compiling in Windows, then everything is fine. But then the code will need to be changed to compile in Linux. Also, when compiling in Windows, how would we handle functions that are the same in both LCLwindows and Windows?

Curtis

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Shane Miller wrote

I would prefer that we add a LINUX.PP file to the LCL and create new functions with these ssame names. That way we don't have to change ANY code except the USES clause. In the USES we would just have to add linux.pp and the winapi calls would be there.

But the linux units is a basic RTL unit, so then you will create big problems on linux - sysutils depends on it for instance, you will get infinite loops etc etc etc.

You MUST create a unique unit name, or you will end up with problems; you need to change the uses clauses anyway, so I think that this is a minor pain.

Michael.

from the howto

SET
^^^^^^^
SET HOMEDRIVE=D:
SET HOMEPATH=\PROGRA~1\CVS

shouldn't this be CVS ?

Marc

Marc Weustink wrote

I'm wondering what to do.

Check in with Shane. They have managed to almost get mwEdit to compile but only after commenting out large amounts of Windows specific code. Those areas will still need to be rewritten or addressed in the LCL to support mwEdit. It is close but still needs lots of work. I believe Shane could really use help with that.

Well, if you want crossplatform development you have to pay a price, in this case it's some $ifdef..

Shane wrote

I certainly could use the help with MWEDIT. If you search (grep) for the

words TODO: you can see an awful lot of procedures and functions that need to be written yet.

Feel free... :-) It'll make mwedit a lot more fun once we get it to compile

OK, second attempt (the first time NT just locked and I loosed all)

I looked at the TODO's and found:

Windows:
GetDC
ReleaseDC
GetObject
SelectObject
DeleteObject
ShowCaret
HideCaret
SetCaretPos
GetSystemMetrics
RecreateWnd

Canvas: (*)
ExtTextOut

Font: (*)
GetTextMetrics
CreateFontIndirect

ScrollBar: (*)
SetScrollInfo
ShowScrollBar

System:
StringOfChar

Menus: (!)
ShortCut
ShortCutToKey

other:
TRegistry
TBitmap.LoadFromResourceName
TFont.Pitch

Now the question how to implement. I think thewre are a few options: 1)
Don't support direct API calls. Use their class counterparts. IE, dont use ExtTextOut(Canvas.Handle, ...) but use Canvas.ExtTextOut(...). This bereaks a lot of compatibility.

2)
Use a platform dependent windows.pp like the classes unit. However there aleady exists a rtl windows.pp (and linux.pp)

3)
Since linux.pp and windows.pp are rtl files, create ONE LCLwindows.pp. This file contains (win)API related implementations for every platform (if it is possible) or just a call to its InterfaceObject(since it's global) counterpart (all platform specific stuff in one place). Like LCLwindows.ExtTextOut calls InterfaceObject.ExtTextOut.

Question is, what way to go. I think I prefer last one. It's only adding a reference to LCLwindows if needed. Any thoughts ?

Marc

(meanwhile doing some menu stuff)

Anyone else having trouble compiling due to the error in thread.inc? Anyone working on this?

Shane

I created a LINUX.PP file and was going to put the stuff in there. ------------------------------------------------------------ Shane Miller

Get paid to surf the net!
http://alladvantage.com/go.asp?refid=DEX-870

Home page : http://www.lakefield.net/~smiller

Auto-IP Publisher : http://www.lakefield.net/~smiller/autoip

Advanced Clipboard : http://www.lakefield.net/~smiller/advclipboard

Lazarus : http://www.miraclec.com/lazarus
----------------------------------------------------------

Hi,
As you might have noticed, I'm back from my holliday trip. After reading loads of email, I'm wondering what to do. The last thing I did was on the notebook, and after that I would have looked at the scrollbar. If I recall it correct, I read somewhere that Cliff continued this.
Further, I read something about the editor. It looks to me if the mwEdit is almost tackled, so need any help there ?
Otherwise, maybe I can look after the (now IMHO incorrect mixed) use of parent and owners, which also touches some curent changes in the menu (getting both straight).

Greetings Marc

You are correct. Jeff be sure to make this change.

I certainly could use the help with MWEDIT. If you search (grep) for the words TODO: you can see an awful lot of procedures and functions that need to be written yet.

Feel free... :-) It'll make mwedit a lot more fun once we get it to compile SHane

>> Marc Weustink 10/26/99 12:38PM >>>

Hi,
As you might have noticed, I'm back from my holliday trip. After reading loads of email, I'm wondering what to do. The last thing I did was on the notebook, and after that I would have looked at the scrollbar. If I recall it correct, I read somewhere that Cliff continued this.
Further, I read something about the editor. It looks to me if the mwEdit is almost tackled, so need any help there ?
Otherwise, maybe I can look after the (now IMHO incorrect mixed) use of parent and owners, which also touches some curent changes in the menu (getting both straight).

Greetings Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Duh,
last saturday everything compiles OK

and today:
gtkcallback.inc(661,85) Error: Cannot access a protected field of an object here
gtkobject.inc(233,45) Error: Cannot access a protected field of an object here gtkobject.inc(234,112) Error: Cannot access a protected field of an object here
gtkobject.inc(1170,4) Error: Cannot access a protected field of an object here Fatal: There were 4 errors compiling module, stopping make: *** [lazarus] Error 1
/mnt/hdc/usr/src/fpc
marc:~/lazarus$

I looked for some CVS changes, I can't find any clue

Marc

Shane wrote

OK, instead lets use a LCLLinux or LCLWin file. Either or, but not both, and put all the winapi stuff in there. I'll rename my LINUX.PP file to one of those. Any preferences?

LCLWin

My vote goes to LCLLinux :-)

Curtis