Shane wrote

Well, it looks like there are quite a few things that need to be done to

make this project a success.

A typecast for a pointer to the object we're talking about ? In most cases in windows the handle is just a pointer to something.

So Canvas.Handle will be a pointer to the GTK_Canvas object. Is should only be adressed as a pointer in the interface objects. (If feel the same for fcomponent being a handle)

2) One of the major things is the FONT stuff. GetObject, CreateFontIndirect, etc all gather font information in

different ways. Would anyone be willing to tackle this?

It seems that it would be best to create these functions in LCLLINUX (or

LCLWIN, depending on if I rename it) and have them either call into gtkinterface to get this info.

Could someone take control of this? This would really help.

Hmm... As far as I can see it could be done with the info in the interface object. I didn't find much more info about fonts in GTK. I'll give it a try (without a font no editor, menus can wait) as soon as I can reach CVS.
Any point to some doc's ??

Marc

What about using FreeType? This would allow to use TTF fonts with all guis?

>>>1) One thing we need to determine is what we are going to use the

property HANDLE for in Linux.

PM dvortex-[gotcha/courrier] wrote

Isn't the handle is specificity of the WindowsXX environment ? I beleive so, and therfore, components shouldn't have access to this property.

Technically, yes, but the concept is usable under any toolkit. With Windows, the handle allows access to constructs (almost used objects, but that wouldn't be quite appropriate) that the operating system normally has control of. Under Linux, the OS doesn't have this concept, nor for the most part does X, but the toolkits do. So the handle will allow access to the widget.

(give me an example of a Lazarus user doing development that would need the .Handle property ?)

The application developer probably won't find -too- many uses for it, just like the Delphi developer doesn't often use it (directly, anyway). The people who will use it the most will be us, the component developers. We have to have a method for doing this, and while possibly (quite probably, really) this isn't the absolute best way to do it, there a few very good reasons to do so. For one, many of us are familiar with how this works, and can move forward much quicker. Another use is to make it much easier to port existing Delphi components. Obviously, they will not just magically work, but the porting effort will be much easier.

the windows.pp can have it and use it internally, but i don't think that it should go through the layers and appear in the LCL.

But it must appear in the LCL for it to be of at the way the Delphi VCL is put together. From the bottom on up, one layer of the VCL inherits from the previous. For instance, how hard would it be to derive a BitButton from a Button if you couldn't use the window handle to intercept the WinProc, and catch the paint message and do your own painting of the canvas? Yes, it can be done other ways. More easily or faster (development or runtime) I am not so sure. This sounds very Windows-centric (and I admit I am) but after all, isn't one of the goals not to be unnecessarily incompatable with Delphi? The odd wording there is deliberate. Obvisously we can't be 100% Delphi compatable.

(am i just shouting garbage ?)

Of course not. You are perfectly right to say that the average developer wouldn't use it. But then, who knows an "average" developer? ;^) And given enough time, I am certain we could find a better way to do things, and still be cross-platform and multiple widget-set capable. But time isn't exactly on our side.

Jeff.

That would work ok I can just set that when creating the widget in the interface object.

Cliff

This is a good idea. This wouldn't be all that hard to do. But another way we could do it is like Delphi does. When Delphi changed the names of some of the files (when it went from Delphi 1 to Delphi 2), they added the concept of having aliases. In the options, you can specify a unit name that equals another unit name. I believe in Delphi 1 the Windows unit was called WinTypes. Then when they changed it to Windows they made that alias system. If you look in the project options, you will see an entry something like WinTypes=Windows. We could do the same thing to alias lcllinux with windows (Windows=LCLLinux). So I think either of these two ways would work.

Curtis

Well, it looks like there are quite a few things that need to be done to make this project a success. I have a few points:

1) One thing we need to determine is what we are going to use the property HANDLE for in Linux. Can we use it for something that will allow us to FIND the correct gtkwidget or QTWidget by using this handle? All the winapi calls pass this handle so it seems that we are going to need to start using this to be compatable.

2) One of the major things is the FONT stuff.

GetObject, CreateFontIndirect, etc all gather font information in different ways. Would anyone be willing to tackle this? It seems that it would be best to create these functions in LCLLINUX (or LCLWIN, depending on if I rename it) and have them either call into gtkinterface to get this info.

Could someone take control of this? This would really help.

3) HideCaret, ShowCaret, ???Caret. We need someone to look into this and create functions that can create/hide/detroy the caret. Can we get a vollunteer?

I will be working on getting the GTK widgets to use the wndproc now so hopefully we can get some of you to give us a hand on these Method's that need to be written. Feel free to ask questions if your not sure where to put them, how to write them, or anything else.

Shane

Isn't the handle is specificity of the WindowsXX environment ?

I beleive so, and therfore, components shouldn't have access to this property.

(give me an example of a Lazarus user doing development that would need the .Handle property ?)

the windows.pp can have it and use it internally, but i don't think that it should go through the layers and appear in the LCL.

(am i just shouting garbage ?)

Handle can point to the name of the QT object.
Instead of passing the name of the LCL component to the QT engine, you simply cast the Handle to a string or pchar and pass that to the QT engine.

Gertjan

For my input here handle means absolutley nothing to the QT engine. If you need to manipulate a component it has to be called by component instance name such as form1 or button1.

Cliff

Shane Miller wrote

It seems that it would be best to create these functions in LCLLINUX (or LCLWIN, depending on if I rename it) and have them either call into gtkinterface to get this info.

It would be really nice, sometime in the distant future, if these issues were handled something like the System unit in Delphi. When the IDE gets going, there is a project option that lets you specify platform, and when you select Windows, then the Uses Windows will use the windows.pp in the win32 rtl, and if you select GTK or QT or whatever, the the Uses Windows will be silently converted to the LCLWin.pp or whatever, all behind the scenes.

I know, dream on.

On a similar vein, does anyone on the list program in Forth? I've been working some with the latest SwiftX environment from Forth Inc, and their platform independence* model is superb, IMHO. It's very hard to explain in words, but easy to use. I was wondering if any of you had seen it. Basically, the IDE resolves all of the dependencies, not the code itself. In other words, based on the platform, it processes the "includes" to get the right version for the hardware. So you develop multiple versions from a common template for the hardware specific stuff (like the FCL/RTL) and a single version for the higher level stuf (like the LCL).

* This isn't OS independence, it is hardware independence, as this is an embedded system development tool, not a traditional application tool.

Jeff.

Great

+ From: Gertjan Schouten
+ Handle can point to the name of the QT object.
+ Instead of passing the name of the LCL component to the QT engine, you
+ simply cast the Handle to a string or pchar and pass that to
+ the QT engine.
+
+
+ Gertjan

To be compatible we need the handle. While waiting till I could reach CVS (some net problems between me and uu.net) and start to do some font stuff, I started to look after the menu, which also involves owners and parents. Then I came to the creation point of components.
It would be nice if it is handled in a way Delphi does. This is after a call to HandleNeeded. I started to try to get this working for menus. In this a Handle is important. The state of Handle 0 determens if the GTK/QT/WIN object is created.
As I said earlier, the Handle should only be a reference (like is it in win32) to the GTK/QT/WIN object and has no meaning in the LCL. It only has a meaning in the interfaces (and there only Handle should be used to retrieve the GTK/QT/WIN object). Something like
GTK: Handle <--> fComponent
QT: Handle <--> PChar(Name)
Win32: Handle <--> Handle

+ ----- Original Message -----
+ From: Cliff Baeseman
+
+ > For my input here handle means absolutley nothing to the QT
+ > engine. If you need to manipulate a component it has to be called by
+ > component instance name such as form1 or button1.
+ >
+ > Cliff

By using Handle (and in your interface PChar(Handle)) all the calls outside the interface would be the same. As we see in parts needed for mwEdit now, many handles are used.

+ > -----Original Message-----
+ > From: dvortex-[gotcha/courrier]

+ >
+ > >Isn't the handle is specificity of the WindowsXX environment ?
+ > >
+ > >I beleive so, and therfore, components shouldn't have
+ > >access to this property.
+ > >
+ > >(give me an example of a Lazarus user doing development
+ > >that would need the .Handle property ?)
+ > >
+ > >the windows.pp can have it and use it internally, but i
+ > >don't think that it should go through the layers and appear in the LCL.
+ > >
+ > >(am i just shouting garbage ?)

Handles are a reference to your GTK/QT/WIN (windows) environment. But components can't do anything without them.

[ snip: Shane and myself about Handles and WinProc ]

Marc

-----Original Message-----

Yesterday, I went through and cleaned up all the mwEdit code. Several of the compatibility issues had been fixed in FPC, so I was able to remove many of the IFDEF's. I also worked on the beta version and have it very close to compiling. I checked everything into CVS.

As I went through the code, I documented all the things that need to be done to get mwEdit working under Linux with FPC. Here is the list I came up with.

mwcustomedit.pas

1) Fix the following which does not work for some reason:
       Font.OnChange := @FontChanged

2) Write the implementation for LoadFromResourceName to load the Mark bitmaps.

3) Write a replacement function for the following Windows functions: GetObject
CreateFontIndirect
GetDC
SelectObject
GetTextMetrics
ReleaseDC
DeleteObject
HideCaret
GetSystemMetrics
ExtTextOut
ShowCaret
SetCaretPos
SetScrollInfo
ShowScrollBar

4) Fix Draw method parameter list of TImageList to match Delphi parameter list.

5) Create a way to perform the following action:

       inherited Font := Value
    where Value is a TFont.

6) Add Pitch to the TFont object.

7) Write a RecreateWnd method.

8) Create the following methods in the parent object (TCustomControl): WMKillFocus
WMNCHitTest
WMSetFocus
WMSize

mwhighlighter.pas

1) Write Registry or Ini file code to replace RegOpenKeyEx.

mwpassyn.pas

1) Fix compiler bug so it will call a function that is being pointed to by an array variable.

Note that these are the things that need to be done to get the release version working. I haven't documented the things that need to be done to get the beta version working, but I expect they will be very similar. If we get the above items working, then it probably won't take much more to get the beta version working.

Anyone who wants to start working on these things, please feel free to jump in and help out. We need to get these things fixed (or figure out other ways to do them) in order to get mwEdit working in Linux.

Thanks....Curtis

That is a great idea. Otherwise, we will need to redo all this again every time they make changes. If we can get them to take our code in as part of the normal distribution, then it will just make mwEdit that much better because it will eventually work with FPC too.

I was just thinking about all this and realized something. FPC has a Windows unit for Windows. All those functions already exist there. I bet we could add {$IFNDEF LINUX} and {$IFDEF WIN32} statements to the existing {$IFDEF MWE_FPC} statements and get mwEdit to compile and "work" in Windows as it is now. This should be OK to do since we are going to create these functions in Linux anyway.

I will make these changes so we can see if it will work. If not, then we can back those changes back out. But since those functions already exist in Windows, there is no reason for us to create them there again. We might be able to get a Windows version of Lazarus working real soon if we can get mwEdit to compile and work in Windows. Then it is just a matter of creating those functions in Linux to get it working in Linux also. Since we will need these functions on any platform we port Lazarus to, we need to be sure to write those functions in some way that can easily be ported to other platforms.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

I fixed # 6. I added the property but it doesn't do anything yet. The functions SETPITCH and GETPITCH need to be "finished" (A.K.A. "started").

Shane

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
1) Fix the following which does not work for some reason:

       Font.OnChange := @FontChanged

2) Write the implementation for LoadFromResourceName to load the Mark bitmaps.

3) Write a replacement function for the following Windows functions: GetObject
CreateFontIndirect
GetDC
SelectObject
GetTextMetrics
ReleaseDC
DeleteObject
HideCaret
GetSystemMetrics
ExtTextOut
ShowCaret
SetCaretPos
SetScrollInfo
ShowScrollBar

4) Fix Draw method parameter list of TImageList to match Delphi parameter list.

5) Create a way to perform the following action:

       inherited Font := Value
    where Value is a TFont.

6) Add Pitch to the TFont object.

7) Write a RecreateWnd method.

8) Create the following methods in the parent object (TCustomControl): WMKillFocus
WMNCHitTest
WMSetFocus
WMSize

mwhighlighter.pas

1) Write Registry or Ini file code to replace RegOpenKeyEx.

mwpassyn.pas

1) Fix compiler bug so it will call a function that is being pointed to by an array variable.

Note that these are the things that need to be done to get the release version working. I haven't documented the things that need to be done to get the beta version working, but I expect they will be very similar. If we get the above items working, then it probably won't take much more to get the beta version working.

Anyone who wants to start working on these things, please feel free to jump in and help out. We need to get these things fixed (or figure out other ways to do them) in order to get mwEdit working in Linux.

Thanks....Curtis

I have sent an email to mwedit's mailing list to see if we can start a dialog abouit the WINAPI fuinctions in the source, along with us giving them our code so any new changes will be made with our code included. I will keep you informed...

Shane

>> Curtis White 11/09/99 09:21AM >>>

Yesterday, I went through and cleaned up all the mwEdit code. Several of the compatibility issues had been fixed in FPC, so I was able to remove many of the IFDEF's. I also worked on the beta version and have it very close to compiling. I checked everything into CVS.

As I went through the code, I documented all the things that need to be done to get mwEdit working under Linux with FPC. Here is the list I came up with.

mwcustomedit.pas

1) Fix the following which does not work for some reason:
       Font.OnChange := @FontChanged

2) Write the implementation for LoadFromResourceName to load the Mark bitmaps.

3) Write a replacement function for the following Windows functions: GetObject
CreateFontIndirect
GetDC
SelectObject
GetTextMetrics
ReleaseDC
DeleteObject
HideCaret
GetSystemMetrics
ExtTextOut
ShowCaret
SetCaretPos
SetScrollInfo
ShowScrollBar

4) Fix Draw method parameter list of TImageList to match Delphi parameter list.

5) Create a way to perform the following action:

       inherited Font := Value
    where Value is a TFont.

6) Add Pitch to the TFont object.

7) Write a RecreateWnd method.

8) Create the following methods in the parent object (TCustomControl): WMKillFocus
WMNCHitTest
WMSetFocus
WMSize

mwhighlighter.pas

1) Write Registry or Ini file code to replace RegOpenKeyEx.

mwpassyn.pas

1) Fix compiler bug so it will call a function that is being pointed to by an array variable.

Note that these are the things that need to be done to get the release version working. I haven't documented the things that need to be done to get the beta version working, but I expect they will be very similar. If we get the above items working, then it probably won't take much more to get the beta version working.

Anyone who wants to start working on these things, please feel free to jump in and help out. We need to get these things fixed (or figure out other ways to do them) in order to get mwEdit working in Linux.

Thanks....Curtis

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

I changed all the release files for mwEdit so it will include the Windows functions under Windows. This may allow it to work when compiled in Windows. But since I don't have FPC installed on Windows, I can't try it. Can someone try compiling the release version of mwEdit (lcl/components/mwedit/release) in Windows? Then try putting it on a form to see if it works?

There are still a couple of FPC specific issues that need to be resolved, so it may have some bugs, but I think it may actually show the control on a form and partially work in Windows now (if we are lucky).

Thanks...Curtis

Cool. I removed the define in mwCustomEdit that was hiding this from the compiler. So now when it is implemented, it will magically start working :-)

Curtis

On 09-Nov-99 Shane Miller wrote

I fixed # 6. I added the property but it doesn't do anything yet. The functions SETPITCH and GETPITCH need to be "finished" (A.K.A. "started").