What's the url for Kassandra again?
------------------------------------------------------------ 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
----------------------------------------------------------

nope I just have straight up procedures right now no class involvement.

Cliff

Shane Miller wrote

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

I'll take on the Registry stuff. It gives me something somewhat simple to do and get me back more into the swing of things. One change I think we should make. I will move it out of the LCL and into the FCL. About the only way we can easily do the Win32 and Linux compatability is to use code for Win32 which uses the real Win32 API and a compatibility version for Linux. Currently the FCL is designed to have both sets of trees. Win32 specific code already exists in the FCL if you are building the FCL for Win32. The Registry really isn't a GUI feature so moving it to the FCL makes sense. Also since that is the location of the TIniFile code it the two would be together.

Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

I believe we have to split up where the information is stored. First off the /etc directory is write only for root. This would equate to the HKEY_LOCAL_LOCAL tree found in the Registry which is only modifiable by an Administration level account (on NT). The HKEY_USERS tree is specific to the current user. This would make sense to have this part of the Registry located in the users HOME directory. The easiest way to make the Registry would be to make it a standard INI file. Again this reduces complexity on the Linux side with the RegIniFile class since it would also just use the IniFile type all the time.

Everyone follow this one??

That would be the ADDRESS of the procedure.

Not sure why you would grab the address that way though. What you should do it set up a type

TSomeType = procedure (myint : integer); cdecl;

then in your class or var area, define a variable of type TSomeType and assign it to myproc. You may be doing it that way for a reason I don't understand though....

Shane

>> "Baeseman, Cliff" 10/19/99 01:00PM >>>

Hi gents!

A little pascal question for you all..

If I declare a procedure like this.

procedure myproc(myint: integer);cdecl;
begin
end;

I then reference it like this @myproc what does this really stand for. It is my assumption that it is a untyped pointer to the address of myproc. Is this assumption
correct?

Cliff

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

I have started adding a TScrollBox to our LCL. I of course need to add a TControlScrollBar, then a TScrollingWinControl, THEN a TScrollbox. Any help would be appreciated. I am updating the LCL to CVS. The code can be found in FORMS.PP Pick a class and add code to it, or add the underlying code into gtkobject. I don't care which, but we NEED this to get the editor working.....

CVS is updated. Post your changes as soon as they are made.....

Thanks
Shane

>> "Shane Miller" 10/18/99 01:59PM >>>

Looks like we need a TScrollBox component. We could use the gtk scrolledwindow I'll look into this and let you know if this can be accomplished easily.

Not sure if this class would be the best one to use.

Shane

>> Sebastian G�nther 10/17/99 05:06AM >>>

Shane Miller wrote

I like the idea of using the same editor. However, aren't our classes and implementation so different that it would require a lot of work?

We could create a special class which has to be implemented differently for each IDE, but all other classes can be the same. This class would have methods for:
- changing the current color and font style
- drawing text
- clearing a rectangle
- drawing the cursor
- clipboard support
- Keyboard handling

All the drawing stuff should not be pixel based, but character cell based, so it can be used even in text mode IDE's.

Regarding this abstraction class: Either we create an interface class (class which contains only abstract virtual methods), or we use include files for the different implementations.

I have attached the latest KCL SHEdit widget source (15 kB); this source won't compile without changes as it would require an unreleased version of KCL. It has clipboard support, but there is a tiny bug when you try to undo and redo a 'paste' operation.

- Sebastian

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

Thanx Michael.

Cliff

Sorry for the last message. Not real readable;. Can't tell my comments from Curtis's comments. Below is a better one...

<Curtis...>
I have also been working hard on getting an editor working.

Shane, I think Sebastian has come up with a way we can get SHEdit working by just implementing the abstract class he is writing. Right now SHEdit inherits from TScrollBox, but we will be changing that to not inherit from anything (I think that is what he said). So I wouldn't spend too much time trying to build all those KCL components. I think with that abstract class, we can just use LCL and FPC code and get it working without all that work.

<Shane..>
I wasn't building ANY KCL component.
I was going to add the TScrollBox that's needed either way in the LCL.

Curtis.....>

I have been working on getting both SHEdit and mwEdit working. I started working on SHEdit, but I decided to wait on it until Sebastian finished that abstract class. Once he has that done, I think it will be easy to get SHEdit working for us.

In the mean time, I started working to get mwEdit to compile with FPC. I am getting close. There are several parts where I am just creating skeleton classes and methods. We will need to write code for these before mwEdit will completely work. But getting it to compile is my first hurdle to overcome. I am keeping track of the classes and methods that we need to get working in order for mwEdit to work.

<Shane...>
Did you create any comments or something that others can look at to see what needs to be finished? If so, I can start adding the code to the skeleton classes....

<Curtis...>
In order to get parts of mwEdit working, I had to add a Registry unit to the LCL and also a Windows unit. The Windows unit is ONLY for compatibility with Delphi. It contains some constants and type definitions and that is all. We need to make sure that nobody puts any M$ Windows API calls in it. I haven't implemented any of the methods in the Registry units because we still need to decide how we are going to implement that in a cross platform manner (meaning, how we will do it in Linux). I checked in the Registry and Windows units to CVS.

Between both of these editors, I think we can get one (or both) of them working very soon now.

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

<Shane...>
Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

Curtis, I think this is a good route to take.
I like mwedit a lot and think that whether we use it or not, we'll get a lot closer to Delphi-Compatable by doing it this way.... If we can create the skeleton for compatability and document what classes and procedures still need code, then we will essentialy be building an easy to follow list of what needs to be done and hopefully we can involve a few other people.

Shane

_________

Shane Miller wrote

I like the idea of using the same editor. However, aren't our classes and implementation so different that it would require a lot of work?

We could create a special class which has to be implemented differently for each IDE, but all other classes can be the same. This class would have methods for:
- changing the current color and font style
- drawing text
- clearing a rectangle
- drawing the cursor
- clipboard support
- Keyboard handling

All the drawing stuff should not be pixel based, but character cell based, so it can be used even in text mode IDE's.

Regarding this abstraction class: Either we create an interface class (class which contains only abstract virtual methods), or we use include files for the different implementations.

I have attached the latest KCL SHEdit widget source (15 kB); this source won't compile without changes as it would require an unreleased version of KCL. It has clipboard support, but there is a tiny bug when you try to undo and redo a 'paste' operation.

- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00000.zip
Type: application/octet-stream
Size: 15212 bytes
Desc: "shedit.zip"
Url : http://localhost/pipermail/lazarus/attachments/19991017/3d190d86/zip00000.obj

I have renamed stdcontrols.pp to stdctrls.pp for compatability. I changed lazarus so it compiles. I tried to

cvs release stdcontrols.pp but it didn't work. Can someone else try it please.

I also added a messages.pp that basically uses lmessages.pp. I only needed it for compatability....

Shane

Curtis, are you settting a define up for Linux in the MWEDIT code? For example, if I simply try to compile I get an error on the InttoIdent call in mwkeycmds.pas. I looked at the code and defined {$DEFINE MWE_COMPILER_2} so that it took the code instead of calling that procedure and it worked fine.

Are you doing anything like that?

Shane

>> Curtis White 10/18/99 11:30PM >>>

I have also been working hard on getting an editor working.

Shane, I think Sebastian has come up with a way we can get SHEdit working by just implementing the abstract class he is writing. Right now SHEdit inherits from TScrollBox, but we will be changing that to not inherit from anything (I think that is what he said). So I wouldn't spend too much time trying to build all those KCL components. I think with that abstract class, we can just use LCL and FPC code and get it working without all that work.

I have been working on getting both SHEdit and mwEdit working. I started working on SHEdit, but I decided to wait on it until Sebastian finished that abstract class. Once he has that done, I think it will be easy to get SHEdit working for us.

In the mean time, I started working to get mwEdit to compile with FPC. I am getting close. There are several parts where I am just creating skeleton classes and methods. We will need to write code for these before mwEdit will completely work. But getting it to compile is my first hurdle to overcome. I am keeping track of the classes and methods that we need to get working in order for mwEdit to work.

In order to get parts of mwEdit working, I had to add a Registry unit to the LCL and also a Windows unit. The Windows unit is ONLY for compatibility with Delphi. It contains some constants and type definitions and that is all. We need to make sure that nobody puts any M$ Windows API calls in it. I haven't implemented any of the methods in the Registry units because we still need to decide how we are going to implement that in a cross platform manner (meaning, how we will do it in Linux). I checked in the Registry and Windows units to CVS.

Between both of these editors, I think we can get one (or both) of them working very soon now.

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

Curtis

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

Curtis White wrote

I also looked through the Kassandra code and it looks to me like it would be pretty easy to convert over to work with Lazarus. It doesn't have as many fancy features as mwEdit, but I think we could have it going faster.

I can send you the latest source which has clipboard support, if you want. We will need some time until the new KCL base is ready, and until then Kassandra is stopped. BTW, I've talked with Florian about this today and we both would like to see a common editor in all IDE's. I would be glad if we could make this reality, because it will save us all a lot of work.

- Sebastian

Looks like we need a TScrollBox component. We could use the gtk scrolledwindow I'll look into this and let you know if this can be accomplished easily.

Not sure if this class would be the best one to use.

Shane

>> Sebastian G�nther 10/17/99 05:06AM >>>

Shane Miller wrote

I like the idea of using the same editor. However, aren't our classes and implementation so different that it would require a lot of work?

We could create a special class which has to be implemented differently for each IDE, but all other classes can be the same. This class would have methods for:
- changing the current color and font style
- drawing text
- clearing a rectangle
- drawing the cursor
- clipboard support
- Keyboard handling

All the drawing stuff should not be pixel based, but character cell based, so it can be used even in text mode IDE's.

Regarding this abstraction class: Either we create an interface class (class which contains only abstract virtual methods), or we use include files for the different implementations.

I have attached the latest KCL SHEdit widget source (15 kB); this source won't compile without changes as it would require an unreleased version of KCL. It has clipboard support, but there is a tiny bug when you try to undo and redo a 'paste' operation.

- Sebastian

Hi gents!

A little pascal question for you all..

If I declare a procedure like this.

procedure myproc(myint: integer);cdecl;
begin
end;

I then reference it like this @myproc what does this really stand for. It is my assumption that it is a untyped pointer to the address of myproc. Is this assumption
correct?

Cliff

I have also been working hard on getting an editor working.

Shane, I think Sebastian has come up with a way we can get SHEdit working by just implementing the abstract class he is writing. Right now SHEdit inherits from TScrollBox, but we will be changing that to not inherit from anything (I think that is what he said). So I wouldn't spend too much time trying to build all those KCL components. I think with that abstract class, we can just use LCL and FPC code and get it working without all that work.

I have been working on getting both SHEdit and mwEdit working. I started working on SHEdit, but I decided to wait on it until Sebastian finished that abstract class. Once he has that done, I think it will be easy to get SHEdit working for us.

In the mean time, I started working to get mwEdit to compile with FPC. I am getting close. There are several parts where I am just creating skeleton classes and methods. We will need to write code for these before mwEdit will completely work. But getting it to compile is my first hurdle to overcome. I am keeping track of the classes and methods that we need to get working in order for mwEdit to work.

In order to get parts of mwEdit working, I had to add a Registry unit to the LCL and also a Windows unit. The Windows unit is ONLY for compatibility with Delphi. It contains some constants and type definitions and that is all. We need to make sure that nobody puts any M$ Windows API calls in it. I haven't implemented any of the methods in the Registry units because we still need to decide how we are going to implement that in a cross platform manner (meaning, how we will do it in Linux). I checked in the Registry and Windows units to CVS.

Between both of these editors, I think we can get one (or both) of them working very soon now.

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

Curtis

i've used this component set - freeware, very good. 'handel' uses it too, an interesting freeware copy of the delphi IDE.

Why don't you take the editor of Kassandra? It works almost already. Only some canvas drawing things were left to be fixed.

Peter

Eventually we can merge it with the text mode version. The only problem with the text mode version is, that it contains already the debug/browsing stuff...

I am trying to figure out the correct way to send this procedure to the lazqtlib. I am getting a crash inside of the C++ library trying to call back the pascal routine. If this is the case and it is a address and not a pointer to an address then I know what is going on. The library is looking for a pointer to an address..

EventHook(char *WidgetID, void *procpointer) I then have to cast this in the library
back to an address and attach it to the appropriate object in the internal widget stack. I get either a access violation or illegal instruction.

Cliff

Oh, OK. I understand now. This way it would be a completely standalone component. That would work very nice. Then we could just put it on a TForm or TNotebook page in Lazarus and it would work. That would be great.

I will simply remove all KCL dependencies and write a simple demo TSHRenderer implementation.

That would be very helpful.

That would be great. Then we could just implement that class using Lazarus components and ways of doing things and you could implement it the KCL way in Kassandra. That would allow both projects to use the same edit control. That would be really good.

BTW, does SHEdit have a way to do Syntax Highlighting of pascal source code? I'm sure it does because it did in the version from your web site. But I didn't see the pascal highlighting code in the version you just sent to the list. Does the new editor work the same way or how does the pascal syntax highlighting work in the new editor?

Also, can we do XML highlighting (I think we are doing our forms in XML) in SHEdit?

If there is anything I can do to help, let me know.

Curtis

Where is this handel site, I seen it once before but cannot find it now.

Cliff

Cliff wrote

Where is this handel site, I seen it once before but cannot find it now.

http://myhome.netsgo.com/wyb330/default.htm

Curtis White wrote

Oh, OK. I understand now. This way it would be a completely standalone component. That would work very nice. Then we could just put it on a TForm or TNotebook page in Lazarus and it would work. That would be great.

Yes. We will have to solve some problems with the keyboard definitions, and we will see what to do with clipboard support, but this problems will be solved.

Oops... The highlighters still are part of Kassandra, whereas I have moved the SHEdit widget to KCL. I will move the highlighters to the SHEdit sources.
The Pascal highlighter can be found in kassandra/src/vw_pas.pp.

Also, can we do XML highlighting (I think we are doing our forms in XML) in SHEdit?

Yes, there is a working XML highlighter in Kassandra, it is included in the 1999/08/29 snapshot (file kassandra/src/vw_xml.pp).

cu,
Sebastian

Is this procedure a member of a class? If so, remember that it also sends SELF although it would be hidden.

Shane

>> "Baeseman, Cliff" 10/19/99 01:27PM >>>

I am trying to figure out the correct way to send this procedure to the lazqtlib. I am getting a crash inside of the C++ library trying to call back the pascal routine. If this is the case and it is a address and not a pointer to an address then I know what is going on. The library is looking for a pointer to an address..

EventHook(char *WidgetID, void *procpointer) I then have to cast this in the library
back to an address and attach it to the appropriate object in the internal widget stack. I get either a access violation or illegal instruction.

Cliff

Sounds correct way to do it for me also.

Cliff

The KCL looks quite a bit different than our LCL, but I think we could probably utilize some of the code from it.

I looked through the Kassandra code and I think we could use its editor with just a few small changes. Most everything is self contained in the editor. The only reference to the KCL that I could find was the TWidget class. When I looked at that class, it looks very similar to our TCustomComponent class (it inherits from TComponent). We could probably substitute our TCustomComponent for TWidget and get the editor working with very few changes.

I will work on this a bit more this afternoon and see if I can get it working. If so, I will let everyone know and if we want, I can hook it up to Lazarus and check it in (I can just rename the current editor file to something else and check it in just in case we want/need to go back to it).

The URL to KCL and Kassandra is http://home.pages.de/~kcl/

Curtis

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

Can you send me the latest source please? I think I can make this editor work without all that much work.

Thanks....Curtis

I like the idea of using the same editor. However, aren't our classes and implementation so different that it would require a lot of work?

------------------------------------------------------------ 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
----------------------------------------------------------

>> Curtis White 10/18/99 11:30PM >>>

I have also been working hard on getting an editor working.

Shane, I think Sebastian has come up with a way we can get SHEdit working by just implementing the abstract class he is writing. Right now SHEdit inherits from TScrollBox, but we will be changing that to not inherit from anything (I think that is what he said). So I wouldn't spend too much time trying to build all those KCL components. I think with that abstract class, we can just use LCL and FPC code and get it working without all that work.

I wasn't building ANY KCL component.
I was going to add the TScrollBox that's needed either way in the LCL.

I have been working on getting both SHEdit and mwEdit working. I started working on SHEdit, but I decided to wait on it until Sebastian finished that abstract class. Once he has that done, I think it will be easy to get SHEdit working for us.

In the mean time, I started working to get mwEdit to compile with FPC. I am getting close. There are several parts where I am just creating skeleton classes and methods. We will need to write code for these before mwEdit will completely work. But getting it to compile is my first hurdle to overcome. I am keeping track of the classes and methods that we need to get working in order for mwEdit to work.

Did you create any comments or something that others can look at to see what needs to be finished? If so, I can start adding the code to the skeleton classes....

In order to get parts of mwEdit working, I had to add a Registry unit to the LCL and also a Windows unit. The Windows unit is ONLY for compatibility with Delphi. It contains some constants and type definitions and that is all. We need to make sure that nobody puts any M$ Windows API calls in it. I haven't implemented any of the methods in the Registry units because we still need to decide how we are going to implement that in a cross platform manner (meaning, how we will do it in Linux). I checked in the Registry and Windows units to CVS.

Between both of these editors, I think we can get one (or both) of them working very soon now.

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

Curtis, I think this is a good route to take.
I like mwedit a lot and think that whether we use it or not, we'll get a lot closer to Delphi-Compatable by doing it this way.... If we can create the skeleton for compatability and document what classes and procedures still need code, then we will essentialy be building an easy to follow list of what needs to be done and hopefully we can involve a few other people.

Shane

You know, I was looking at that mwEdit and starting compiling mwEdit and working to fix the problems. There is a fair amount of Windows specific code in it that we would need to figure out ways to work out.

I also looked through the Kassandra code and it looks to me like it would be pretty easy to convert over to work with Lazarus. It doesn't have as many fancy features as mwEdit, but I think we could have it going faster.

So what do you all think? Should we go with the faster solution that we could have working right away and is pretty good, or should we go with the really good solution that would take a fair amount longer to get working?

Curtis

Hi!

Some time ago I've downloaded one interesting Delphi component - free source, VCL based editor - no use of Windows edit control (at least they say so). Its home page is http://www.eccentrica.org/gabr/mw/mwedit.htm Maybe you can make use of it.

Question:
Would it be a good idea to take the mwedit source, and try to get it to compile and run in our source? This would accomplish 2 things. 1: We would have specific things we knew we needed to get working. 2: When we got it working, we'd have an editor!

I think this may be a good way to do this. Compile some code and see where the errors are and fix them. Once all the errors are fixed (and we are close to Delphi compatable) then we would have an editor that we could all use! Any thoughts? It's an awfully nice editor...

Shane

Hi!

Some time ago I've downloaded one interesting Delphi component - free source, VCL based editor - no use of Windows edit control (at least they say so). Its home page is http://www.eccentrica.org/gabr/mw/mwedit.htm Maybe you can make use of it.

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

Curtis White wrote

So would this special abstract class replace the TScrollBox class that TSHTextEdit currently inherits from? Or would it be used some other way?

Probably it would be the best when TSHTextEdit doesn't derive from any class and to introduce a 'rendering engine' class (TSHRenderer or similar). TSHTextEdit would get a 'property Renderer: TRenderer' then.

I looked at the SHEdit control, but I am having a bit of trouble following it since, like you said, it uses some code from the new KCL that you haven't released yet. I'm just trying to figure out how we could hook it into Lazarus but am having a little trouble being able to tell how we could do it.

I will simply remove all KCL dependencies and write a simple demo TSHRenderer implementation.

You would probably need to be the one to create this abstract class since you know what all SHEdit needs from it in order to work. Would you be willing to create that abstract class?

Yes, but this will take 1-2 days.

cu,
Sebastian

So would this special abstract class replace the TScrollBox class that TSHTextEdit currently inherits from? Or would it be used some other way?

I looked at the SHEdit control, but I am having a bit of trouble following it since, like you said, it uses some code from the new KCL that you haven't released yet. I'm just trying to figure out how we could hook it into Lazarus but am having a little trouble being able to tell how we could do it.

You would probably need to be the one to create this abstract class since you know what all SHEdit needs from it in order to work. Would you be willing to create that abstract class?

But the windows unit is present in the RTL of win32. You should not use it directly in the LCL !

To implement a registry, you should do something like

{$ifdef win32}
Function SomeRegistryCall(); stdcall; external 'kernel32' name '...';
..
{$endif }
{$ifdef linux}
FUnction SomeRegistryCall();
begin
  // Code for linux emulation of registry...
end;
{$endif}

Putting the 'windows' unit in the LCL will create problems with portability.

How would you do it on Linux ? One big 'Ini' file in /etc ? You'll have to agree on a location for this.

Michael.

I have looked at this source code in the past. I will have to review it again, but they are doing basically what I was (I think) using the canvas as the editor and drawing on it.

I guess I should review their code again to see if I am right. I was thinking that it wasn't free to use though....

Shane

>> " (F�****** **********" < 10/14/99 05:38AM >>>

Hi!

Some time ago I've downloaded one interesting Delphi component - free source, VCL based editor - no use of Windows edit control (at least they say so). Its home page is http://www.eccentrica.org/gabr/mw/mwedit.htm Maybe you can make use of it.

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

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful. Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

You may also want to decide how to handle system parameters versus program parameters. Only "Software" registry entries really make any kind of sense under Linux, things like Current User and Local Machine would be a nightmare to make system independent. I mean, it could be done, but who would want to?

Jeff.

Curtis, here are the changes I have made up to this point....

Issues: TShortCut should be moved to Classes instead of Menus.pp (IMHO)

Added ....
FShortCut to TMenuItems.
Procedure SetShortCut(Value : TShortCut);
Proceure MenuChanged(Rebuild : Boolean);
property ShortCut: TShortCut read FShortCut write SetShortCut;
function shortcut(Key : Word; Shift : TSHiftState) : TShortCut;   (added as a lone-function.  Not part of a class.)
Proceudre ShortCuttoKey(blah blah blah);
The code for these are at the end of Menus.pp

Added a bunch of virtual keys intro windows.pp

Problem: How do we deal with typeinfo? Not sure what to do with that.........

Shane

Sounds good to me. Are you done yet? :-)

Shane

>> "Michael A. Hess" 10/19/99 11:02AM >>>

Shane Miller wrote

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

I'll take on the Registry stuff. It gives me something somewhat simple to do and get me back more into the swing of things. One change I think we should make. I will move it out of the LCL and into the FCL. About the only way we can easily do the Win32 and Linux compatability is to use code for Win32 which uses the real Win32 API and a compatibility version for Linux. Currently the FCL is designed to have both sets of trees. Win32 specific code already exists in the FCL if you are building the FCL for Win32. The Registry really isn't a GUI feature so moving it to the FCL makes sense. Also since that is the location of the TIniFile code it the two would be together.

Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

I believe we have to split up where the information is stored. First off the /etc directory is write only for root. This would equate to the HKEY_LOCAL_LOCAL tree found in the Registry which is only modifiable by an Administration level account (on NT). The HKEY_USERS tree is specific to the current user. This would make sense to have this part of the Registry located in the users HOME directory. The easiest way to make the Registry would be to make it a standard INI file. Again this reduces complexity on the Linux side with the RegIniFile class since it would also just use the IniFile type all the time.

Everyone follow this one??

Using GTK's scrolledwindow has a small problem: I haven't found a possibility to avoid the redrawing of the whole widget when the virtual size changes (i.e. if the number of lines changes). This results in very ugly flickering effects as soon as you press the enter key or insert some lines of text from the clipboard. The next version of the SHEdit component for KCL would be based on a new widget with KCL controllable scroll bars.

- Sebastian

I think it might be a good idea for 2 reasons.

1. It might help us get to the working editor part of the LCL quicker. It is already a proven component for doing editing. The web pages does profess that it doesn't use any Windows API calls so we should be able to match functionality. The web page indicates it is free for non-commercial use.

2. Alot of Win32 Delphi coders are already familiar with the component and use it in their Win32 products. By porting it to the LCL it means that various Win32 applications that already use it in Delphi would be portable to the LCL.

I like the idea of trying to compile it with the LCL and see what breaks. Then we work on fixing those items. It already has all of the syntax highlighting for various languages built in. The logic has already been fleshed out we just need to code the LCL to match the feature set it requires.

Talk to him about what we would like to do and see if the author wouldn't be interested in helping. He know his code the best.

absolutely.

Yes, you are right. I am working with the beta version. I figured that our code isn't beyond beta and by the time we get it working, it will probably be a release version. Since the beta will be closer to the release version, I thought it would be easier to get from there to the next version than from the release version. But if you all think we should use the release version, that is fine with me. Like you, I would just like to get an editor going soon. I think that will help motivate more people to help.

Curtis

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

I had to add TColor = longint to graphics.pp. In doing so I found an "issue". We currently declare TColor in LMessages.pp because there are some message constructs that use TColor. We can't simply add graphics.pp to LMEssages because Graphics.pp also used LMesssages and it CAN'T be placed after the implementation.

The reason we are using lmessages in graphics.pp is because a few procedures use the "message LM_Changed" syntax.

We need to find a way around that. Delphi does it by using a IChangeNotifier interface....

Any thoughts?

Shane

I was working with the release version of mwedit, not the internal beta. Looks like you have more files than I do so I assume you are working with the beta version?

Shane

>> Curtis White 10/19/99 10:24PM >>>

OK. I will do it this way.

I haven't changed any of the actual code in mwEdit. Anything that I needed to change, I enclosed in the MWE_FPC defines and then did an ELSE for the original code. So it will still complile exactly the same as it does now in Delphi, but it will also be able to compile with FPC. But I am wondering how much you have compiling because if you have more compiling than I do, then it might be better to use your code. Or maybe we can combine what we both have and have more of it compiling.

Here are the units I have compiling so far:

mwKeyCmds.pas
mwLocalStr.pas
mwSupportClasses.pas
mwSupportProcs.pas
mwHighlighter.pas

The only other units that must compile to get this whole thing compiling are:

cbUtils.pas
mwCustomEdit.pas
mwEditSearch.pas
mwEditStrings.pas
mwExport.pas
mwGeneralSyn.pas
mwHtmlExport.pas
mwRtfExport.pas
uTextDrawer.pas

I will probably be able to get most of these to compile tonight (hopefully).

All the rest of the files in the .zip file are utility classes and highlighters (pascal, c++, etc.). I moved all the files that are not necessary to get the editor working into subdirectories (highlighters, exporters, examples and notneeded). So we can compile that parts that we want/need as we need them (if we want to add other highlighters). I will keep this directory structure when I put them in CVS so that we have all the units and people can work on them as they want.

It would be nice to get the entire thing compiling and working with FPC and LCL (including all the highlighters, exporters, examples, etc.). Then we could submit it back to the original maintainer. That would make it all that much better for people using it. It would also give us more presence in the Delphi community :-)

Curtis

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

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

> Issues: TShortCut should be moved to Classes instead of Menus.pp (IMHO) In Delphi, it exists in menus.pas. That is why I put it there.

Not in Delhpi 5. :-)

------------------------------------------------------------ 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
----------------------------------------------------------

REMOVE, not release!

:-) Done...

Shane

>> "Baeseman, Cliff" 10/19/99 01:27PM >>>

I am trying to figure out the correct way to send this procedure to the lazqtlib. I am getting a crash inside of the C++ library trying to call back the pascal routine. If this is the case and it is a address and not a pointer to an address then I know what is going on. The library is looking for a pointer to an address..

EventHook(char *WidgetID, void *procpointer) I then have to cast this in the library
back to an address and attach it to the appropriate object in the internal widget stack. I get either a access violation or illegal instruction.

Cliff

I am supposed to be working on the clipboard class. I have the class files created for it, but I haven't written the clipboard code yet. I have been studying the XWindows clipboard quite a bit and it is fairly complex. But I think I can get some of the Text clipboard functionality working.

I saw the other email where Sebastian sent the clipboard code he wrote for the KCL. I will look at this code. Maybe that will give us our clipboard functionality to start with and we can expand on it later (to include other formats besides text).

Curtis

On 19-Oct-99 Shane Miller wrote

Curtis, here are the changes I have made up to this point.... Issues: TShortCut should be moved to Classes instead of Menus.pp (IMHO)

In Delphi, it exists in menus.pas. That is why I put it there.

Great. That will really help. These are a couple of the shell functions that I just blocked out with the MWE_LAZ_FIX_LATER define :-)

Added a bunch of virtual keys intro windows.pp

Great. Now we just need to figure out how to deal with these virtual keys in Linux :-) I thought about this a little bit and we might be able to create a conversion function that we pass in a virtual key (VK_F1) and it returns the proper value that should be used in Linux. This function will need to call out to the gtkint units because it will be different on each platform. Any other ideas how we can deal with virtual keys?

Problem: How do we deal with typeinfo? Not sure what to do with that.........

That is a good question. I'm not sure yet either. Can we just do it as a Record or something? I don't know.

Curtis

Just an FYI for anyone developing in Linux. Until we get the editor for Lazarus going, I found this pretty nice editor for Linux called cooledit. It does syntax highlighting of all kinds of different languages, including "Pascal". It is actually pretty nice and really helps me when working with pascal. You can find it at:

http://www.netins.net/showcase/Comput-IT/cooledit/index.html

Curtis

Get the initial implementation of the registry added ASAP. Just define the procedures then work from there. That way we can continue along with getting MWEdit working.....

I'm so demanding huh? :-)
I think we are making good progress this way. Lets continue keeping everyone abreast of the changes and the procedures that need to be coded yet.

We are getting closer to getting mwedit to compile. That's only the first step of course. Once that's complete, we'll need to code the proceudres it calls...

Shane

>> "Michael A. Hess" 10/19/99 11:02AM >>>

Shane Miller wrote

If anyone wants to start working out some way to implement the Registry units so they work in both Windows and Linux, that would be very helpful.

I'll take on the Registry stuff. It gives me something somewhat simple to do and get me back more into the swing of things. One change I think we should make. I will move it out of the LCL and into the FCL. About the only way we can easily do the Win32 and Linux compatability is to use code for Win32 which uses the real Win32 API and a compatibility version for Linux. Currently the FCL is designed to have both sets of trees. Win32 specific code already exists in the FCL if you are building the FCL for Win32. The Registry really isn't a GUI feature so moving it to the FCL makes sense. Also since that is the location of the TIniFile code it the two would be together.

Where should the reg file be stored? Should we put it in the /etc (like suggested) and make it a flat text file or create something a bit more complicated? Any suggestions on what type of file it should be? Hate to do it poorly.

I believe we have to split up where the information is stored. First off the /etc directory is write only for root. This would equate to the HKEY_LOCAL_LOCAL tree found in the Registry which is only modifiable by an Administration level account (on NT). The HKEY_USERS tree is specific to the current user. This would make sense to have this part of the Registry located in the users HOME directory. The easiest way to make the Registry would be to make it a standard INI file. Again this reduces complexity on the Linux side with the RegIniFile class since it would also just use the IniFile type all the time.

Everyone follow this one??

cooledit is also the builtin editor in the console version of mc. I've created the pascal highlighting for it, becuase i use it also a lot for editing under linux.

Peter

we need clipbrd code. Is anyone working on getting the clipboard functions written?

Shane

>> "Shane Miller" 10/19/99 01:55PM >>>

Is this procedure a member of a class? If so, remember that it also sends SELF although it would be hidden.

Shane

>> "Baeseman, Cliff" 10/19/99 01:27PM >>>

I am trying to figure out the correct way to send this procedure to the lazqtlib. I am getting a crash inside of the C++ library trying to call back the pascal routine. If this is the case and it is a address and not a pointer to an address then I know what is going on. The library is looking for a pointer to an address..

EventHook(char *WidgetID, void *procpointer) I then have to cast this in the library
back to an address and attach it to the appropriate object in the internal widget stack. I get either a access violation or illegal instruction.

Cliff

Shane Miller wrote

Get the initial implementation of the registry added ASAP. Just define the procedures then work from there. That way we can continue along with getting MWEdit working.....

Curtis has already done that much. It is currently in the LCL so you should be able to continue as planned. I will leave that as is and start coding it for inclusion in the FCL. When I have that done and commited I remove the LCL code.

Changes:

Added
TDragState to Controls.pp
Added a bunch of Message records to Message.pp and some const.

Shane Miller wrote

Get the initial implementation of the registry added ASAP.

Why don't you use XML files for storing registry-like data?

That way we can continue along with getting MWEdit working....

I'm still in the process of rewriting some parts of SHEdit. This takes somewhat more time than planned, as I'm trying to make it work even with textmode IDE's.

- Sebastian

OK. I will do it this way.

I haven't changed any of the actual code in mwEdit. Anything that I needed to change, I enclosed in the MWE_FPC defines and then did an ELSE for the original code. So it will still complile exactly the same as it does now in Delphi, but it will also be able to compile with FPC. But I am wondering how much you have compiling because if you have more compiling than I do, then it might be better to use your code. Or maybe we can combine what we both have and have more of it compiling.

Here are the units I have compiling so far:

mwKeyCmds.pas
mwLocalStr.pas
mwSupportClasses.pas
mwSupportProcs.pas
mwHighlighter.pas

The only other units that must compile to get this whole thing compiling are:

cbUtils.pas
mwCustomEdit.pas
mwEditSearch.pas
mwEditStrings.pas
mwExport.pas
mwGeneralSyn.pas
mwHtmlExport.pas
mwRtfExport.pas
uTextDrawer.pas

I will probably be able to get most of these to compile tonight (hopefully).

All the rest of the files in the .zip file are utility classes and highlighters (pascal, c++, etc.). I moved all the files that are not necessary to get the editor working into subdirectories (highlighters, exporters, examples and notneeded). So we can compile that parts that we want/need as we need them (if we want to add other highlighters). I will keep this directory structure when I put them in CVS so that we have all the units and people can work on them as they want.

It would be nice to get the entire thing compiling and working with FPC and LCL (including all the highlighters, exporters, examples, etc.). Then we could submit it back to the original maintainer. That would make it all that much better for people using it. It would also give us more presence in the Delphi community :-)

Curtis

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

I came upon two problems in the cbUtils unit when working to compile mwEdit that I don't know exactly how to fix. I don't know if they are compiler bugs or something else. Can someone take a look at the following and tell me how I can fix it for FPC?

In the cbUtils unit, are the following definitions:

  TSpeedListObject = class
  protected
    FName: String;
    FSpeedList: TSpeedStringList;
    procedure SetName(const Value: String); virtual;
  public
    Property Name: String read FName write SetName;
    {$IFDEF MWE_FPC}
    constructor create(aname: string);
    {$ELSE}
    constructor create(name: string);
    {$ENDIF}
    destructor destroy; override;
    property SpeedList: TSpeedStringList read FSpeedList write FSpeedList;
  end;
  PSpeedListObjects = ^TSpeedListObjects;
  TSpeedListObjects = array [0..0] of TSpeedListObject;
  TSpeedStringList = class
  private
    function GetText: string;
    procedure SetText(const Value: string);
  Protected
    FOnChange: TNotifyEvent;
    SumOfUsed: array [0..NbSubList-1] of integer;
    datasUsed: array [0..NbSubList-1] of integer;
    datas: array [0..NbSubList-1] of PSpeedListObjects;
    lengthDatas: array [0..NbSubList-1] of integer;
    procedure Changed; virtual;
    function Get(Index: Integer): string; virtual;
    function GetObject(Index: Integer): TSpeedListObject;
    function GetCount: integer;
    Function GetStringList: TStrings;
    Procedure SetStringList(const value: TStrings);
  public
    Procedure NameChange(const obj: TSpeedListObject; const NewName: String);
    Procedure ObjectDeleted(const obj: TSpeedListObject);
    destructor Destroy; override;
    constructor create;
    function Add(const Value: TSpeedListObject): Integer;
    procedure Clear;
    function Find(const name: String): TSpeedListObject;
    property OnChange: TNotifyEvent read FOnChange write FOnChange;
    property Objects[Index: Integer]: TSpeedListObject read GetObject;
    property Strings[Index: Integer]: string read Get; default;
    property count: integer read GetCount;
    Property StringList: TStrings read GetStringList write SetStringList;
    property text: string read GetText write SetText;
  end;

Then the function below implements the Add function.

function TSpeedStringList.Add(const Value: TSpeedListObject): Integer;
var
  crc: integer;
  i: integer;
begin
  crc:= StringCrc(Value.Name) mod (High(Datas)+1);
  if DatasUsed[crc]=lengthDatas[crc] then begin
    {$IFDEF MWE_FPC}
    ReallocMem(datas[crc], DatasUsed[crc],
(lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ELSE}
    ReallocMem(datas[crc], (lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ENDIF}
    lengthDatas[crc] := lengthDatas[crc]*2+1;
  end;
  Datas[crc][DatasUsed[crc]]:= Value;
  result:= SumOfUsed[crc]+DatasUsed[crc];
  inc(DatasUsed[crc]);
  for i:= crc+1 to High(SumOfUsed) do
    inc(SumOfUsed[i]);
  Value.SpeedList:= Self;
end;

The first problem I had was in the constructor of the TSpeedListObject. It passes in a parameter called "name". There is also a property called name. When I tried to compile this, it had a problem because the compiler confused the parameter with the property and gave me an error stating that Name was already defined. I put in the MWE_FPC defines as above and renamed it to "aname" and it compiles fine. Is this a possible bug in the compiler, or is it a bug in Delphi that allows it?

The second problem is in the implementation of the Add method above. The following line

    Datas[crc][DatasUsed[crc]]:= Value;

causes the following compiler error

Incompatible types: got "TSPEEDLISTOBJECT" expected "TSPEEDLISTOBJECTS"

It looks to me like it is trying to do some sort of two dimensional array or something. I don't understand what this is doing, so I don't know how to fix it. Can someone explain what this is doing and how I an fix it to work in FPC?

Again, if you don't understand my message, just try compiling the cbUtils.pas unit in the mwEdit directory. I am committing the changes I have made to CVS so it will have the same code I am working on.

Curtis

All all the functions defined already? What unit are they in?

------------------------------------------------------------ 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
----------------------------------------------------------

Shane Miller wrote

we need clipbrd code. Is anyone working on getting the clipboard functions written?

KCL has a dummy implementation for clipboard support, which is completely OS independent. (i.e. it works as an internal clipboard) It works like Delphi's clipboard class, except that I replaced the format identifiers with MIME types.
See attachment...

- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00001.zip
Type: application/octet-stream
Size: 2006 bytes
Desc: "clipbrd.zip"
Url : http://localhost/pipermail/lazarus/attachments/19991019/36f18c2d/zip00001.obj

I will try that one tonight and see if it cures the problem, looks reasonable.

BTW you can use the com interface if you have the new DX libraries....

Cliff

I agree. I think XML would provide us a lot more flexibility.

Curtis

Here's howq I do it when iterfacing with DirectX
Direct X needs a callback to enumerate the video resolutions for your video card. When I do is this:

type
TDDEnumCallBackProc = function (lpDDSurfaceDesc: TDDSurfaceDesc2; lpContext : Pointer) : HResult; stdcall;
Implementation
Function ENumModesLocalCallBack2(lpDDSurfaceDesc: TDDSurfaceDesc2; lpContext: Pointer) : Bool;
//then when I call the procedure and pass the callback I do this:
lpDirectDraw4.EnumDisplayModes(0,lpDDSurfaceDesc,lpContext,TDDEnumCallBackProc(EnumModesLocalCallBack(lpDDSurfaceDesc2,lpContext)));
//It's that simple!

Shane

>> "Baeseman, Cliff" 10/19/99 02:02PM >>>

nope I just have straight up procedures right now no class involvement.

Cliff

Now I really like that idea..

Cliff

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

Sebastian G�nther wrote

Why don't you use XML files for storing registry-like data?

Hmmmm. Hadn't thought of that. I was just thinking in terms of using the same code as the TIniFiles but it might make alot more sense to use XML for the Registry on non-Win32 platforms. The XML stuff is already there so it shouldn't be a big deal. That's how I'll do it.

Peter Vreman wrote

cooledit is also the builtin editor in the console version of mc. I've created the pascal highlighting for it, becuase i use it also a lot for editing under linux.

I use it in mc ALL the time. It is my editor of choice at this point in time. I have also tweeked it to do correct pascal highlighting and highly recommend it.

Curtis

see my comment and rewrite below this may fix it then again it may not

Cliff

Yes, I sure did. I setup a define called MWE_FPC. I also created one called MWE_LAZ_FIX_LATER. For things that need to be fixed later, I am putting them in this. Then we can just define MWE_LAZ_FIX_LATER and we will find all the things that need to be fixed in order to make it work. I am doing this first because I just want to get it to compile. Then we can work on fixing the missing pieces. At the top of mwedit.inc, I also defined one called VER90 enclosed in and IFDEF. This forces it to compile in Delphi 2 mode. Basically, here is what I added to mwedit.inc:

{$DEFINE MWE_FPC}
{$IFDEF MWE_FPC}
  { Uncomment the following line when ready to find things that
    need to be fixed for Lazarus }
  //{$DEFINE MWE_LAZ_FIX_LATER}
  {$DEFINE VER90}
  {$MODE OBJFPC}
{$ENDIF}

If you all want me to check in what I have so far, I can do that. But there are several units and it still doesn't compile yet. But I am getting closer. I have several of the units compiling now.

Should we create a directory somewhere in the lazarus path to put this editor in so it isn't mixed in with the other lazarus code? Then when we get it working, we can combine it with the other code. If you all want me to do this, let me know and I will create a directory and check it into CVS. Otherwise, I will just keep working on it to get it to compile. It's up to you all..

Curtis

OK, I created the directory structure that you specified in CVS and checked in all the mwEdit files that I have been working on. I have been working to get the mwEditSearch.pas file to compile tonight and have it close to compiling, but not quite there yet.

Now that it is checked in, anyone can work on getting it to compile. If anyone decides to work on it, just make sure that you don't break the code from working in Windows. I have actually done this myself, but I will fix it tomorrow evening. In the places where I put in code for MWE_LAZ_FIX_LATER, I should have enclosed it in {$IFDEF MWE_FPC} as follows:

{$IFDEF MWE_FPC}
   {$IFDEF MWE_LAZ_FIX_LATER}
       WindowsFunction
   {$ENDIF}
{$ELSE}
  WindowsFunction
{$ENDIF}

If we do it this way, then it will continue to work in Windows. I need to fix these tomorrow evening. Other than that, it is just a matter of compiling and where it stops, adding either the code above or fixing the problem in the LCL.

Then when we have everything compiling, we can just define MWE_LAZ_FIX_LATER in the mwedit.inc unit and the compiler will show us all the broken code that we need to find a way to do in the LCL.

Also, I created a Makefile for the component. So you should be able to just do
a make in the mwedit directory to build the code.

Curtis

I came upon two problems in the cbUtils unit when working to compile mwEdit that I don't know exactly how to fix. I don't know if they are compiler bugs or something else. Can someone take a look at the following and tell me how I can fix it for FPC?

In the cbUtils unit, are the following definitions:

  TSpeedListObject = class
  protected
    FName: String;
    FSpeedList: TSpeedStringList;
    procedure SetName(const Value: String); virtual;
  public
    Property Name: String read FName write SetName;
    {$IFDEF MWE_FPC}
    constructor create(aname: string);
    {$ELSE}
    constructor create(name: string);
    {$ENDIF}
    destructor destroy; override;
    property SpeedList: TSpeedStringList read FSpeedList write FSpeedList;
  end;
  PSpeedListObjects = ^TSpeedListObjects;
  TSpeedListObjects = array [0..0] of TSpeedListObject;
  TSpeedStringList = class
  private
    function GetText: string;
    procedure SetText(const Value: string);
  Protected
    FOnChange: TNotifyEvent;
    SumOfUsed: array [0..NbSubList-1] of integer;
    datasUsed: array [0..NbSubList-1] of integer;
    datas: array [0..NbSubList-1] of PSpeedListObjects;
    lengthDatas: array [0..NbSubList-1] of integer;
    procedure Changed; virtual;
    function Get(Index: Integer): string; virtual;
    function GetObject(Index: Integer): TSpeedListObject;
    function GetCount: integer;
    Function GetStringList: TStrings;
    Procedure SetStringList(const value: TStrings);
  public
    Procedure NameChange(const obj: TSpeedListObject; const NewName: String);
    Procedure ObjectDeleted(const obj: TSpeedListObject);
    destructor Destroy; override;
    constructor create;
    function Add(const Value: TSpeedListObject): Integer;
    procedure Clear;
    function Find(const name: String): TSpeedListObject;
    property OnChange: TNotifyEvent read FOnChange write FOnChange;
    property Objects[Index: Integer]: TSpeedListObject read GetObject;
    property Strings[Index: Integer]: string read Get; default;
    property count: integer read GetCount;
    Property StringList: TStrings read GetStringList write SetStringList;
    property text: string read GetText write SetText;
  end;

Then the function below implements the Add function.

function TSpeedStringList.Add(const Value: TSpeedListObject): Integer;
var
  crc: integer;
  i: integer;
begin
  crc:= StringCrc(Value.Name) mod (High(Datas)+1);
  if DatasUsed[crc]=lengthDatas[crc] then begin
    {$IFDEF MWE_FPC}
    ReallocMem(datas[crc], DatasUsed[crc],
(lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ELSE}
    ReallocMem(datas[crc], (lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ENDIF}
    lengthDatas[crc] := lengthDatas[crc]*2+1;
  end;
  Datas[crc][DatasUsed[crc]]:= Value;
  result:= SumOfUsed[crc]+DatasUsed[crc];
  inc(DatasUsed[crc]);
  for i:= crc+1 to High(SumOfUsed) do
    inc(SumOfUsed[i]);
  Value.SpeedList:= Self;
end;

The first problem I had was in the constructor of the TSpeedListObject. It passes in a parameter called "name". There is also a property called name. When I tried to compile this, it had a problem because the compiler confused the parameter with the property and gave me an error stating that Name was already defined. I put in the MWE_FPC defines as above and renamed it to "aname" and it compiles fine. Is this a possible bug in the compiler, or is it a bug in Delphi that allows it?

The second problem is in the implementation of the Add method above. The following line

    Datas[crc][DatasUsed[crc]]:= Value;

causes the following compiler error

Incompatible types: got "TSPEEDLISTOBJECT" expected "TSPEEDLISTOBJECTS"

It looks to me like it is trying to do some sort of two dimensional array or something. I don't understand what this is doing, so I don't know how to fix it. Can someone explain what this is doing and how I an fix it to work in FPC?

Again, if you don't understand my message, just try compiling the cbUtils.pas unit in the mwEdit directory. I am committing the changes I have made to CVS so it will have the same code I am working on.

Curtis

Well, I have some more of the mwEdit units compiling with FPC. I am getting close now to having the entire thing compiling. The following are all the units that compile now:

cbUtils.pas
mwEditSearch.pas
mwGeneralSyn.pas
mwHighlighter.pas
mwKeyCmds.pas
mwLocalStr.pas
mwSupportClasses.pas
mwSupportProcs.pas

The following are the units that are left to be edited to compile:

mwCompletionProposal.pas
mwCustomEdit.pas
mwEditStrings.pas
mwExport.pas
mwHtmlExport.pas
mwRtfExport.pas
uTextDrawer.pas

I have the mwEditStrings almost compiling, but there are still a few errors to fix. Remember, that I am just adding IFDEFS to make it compile and fixing things where I can easily. We will still need to enable the MWE_LAZ_FIX_LATER define and compile to find the things that we need to fix once it is compiling.

I will keep working on it until I have it compiling. Then I will probably need help to implement the parts that need to be fixed once it is compiling.

Curtis

I came upon two problems in the cbUtils unit when working to compile mwEdit that I don't know exactly how to fix. I don't know if they are compiler bugs or something else. Can someone take a look at the following and tell me how I can fix it for FPC?

In the cbUtils unit, are the following definitions:

  TSpeedListObject = class
  protected
    FName: String;
    FSpeedList: TSpeedStringList;
    procedure SetName(const Value: String); virtual;
  public
    Property Name: String read FName write SetName;
    {$IFDEF MWE_FPC}
    constructor create(aname: string);
    {$ELSE}
    constructor create(name: string);
    {$ENDIF}
    destructor destroy; override;
    property SpeedList: TSpeedStringList read FSpeedList write FSpeedList;
  end;
  PSpeedListObjects = ^TSpeedListObjects;
  TSpeedListObjects = array [0..0] of TSpeedListObject;
  TSpeedStringList = class
  private
    function GetText: string;
    procedure SetText(const Value: string);
  Protected
    FOnChange: TNotifyEvent;
    SumOfUsed: array [0..NbSubList-1] of integer;
    datasUsed: array [0..NbSubList-1] of integer;
    datas: array [0..NbSubList-1] of PSpeedListObjects;
    lengthDatas: array [0..NbSubList-1] of integer;
    procedure Changed; virtual;
    function Get(Index: Integer): string; virtual;
    function GetObject(Index: Integer): TSpeedListObject;
    function GetCount: integer;
    Function GetStringList: TStrings;
    Procedure SetStringList(const value: TStrings);
  public
    Procedure NameChange(const obj: TSpeedListObject; const NewName: String);
    Procedure ObjectDeleted(const obj: TSpeedListObject);
    destructor Destroy; override;
    constructor create;
    function Add(const Value: TSpeedListObject): Integer;
    procedure Clear;
    function Find(const name: String): TSpeedListObject;
    property OnChange: TNotifyEvent read FOnChange write FOnChange;
    property Objects[Index: Integer]: TSpeedListObject read GetObject;
    property Strings[Index: Integer]: string read Get; default;
    property count: integer read GetCount;
    Property StringList: TStrings read GetStringList write SetStringList;
    property text: string read GetText write SetText;
  end;

Then the function below implements the Add function.

function TSpeedStringList.Add(const Value: TSpeedListObject): Integer;
var
  crc: integer;
  i: integer;
begin
  crc:= StringCrc(Value.Name) mod (High(Datas)+1);
  if DatasUsed[crc]=lengthDatas[crc] then begin
    {$IFDEF MWE_FPC}
    ReallocMem(datas[crc], DatasUsed[crc],
(lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ELSE}
    ReallocMem(datas[crc], (lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ENDIF}
    lengthDatas[crc] := lengthDatas[crc]*2+1;
  end;
  Datas[crc][DatasUsed[crc]]:= Value;
  result:= SumOfUsed[crc]+DatasUsed[crc];
  inc(DatasUsed[crc]);
  for i:= crc+1 to High(SumOfUsed) do
    inc(SumOfUsed[i]);
  Value.SpeedList:= Self;
end;

The first problem I had was in the constructor of the TSpeedListObject. It passes in a parameter called "name". There is also a property called name. When I tried to compile this, it had a problem because the compiler confused the parameter with the property and gave me an error stating that Name was already defined. I put in the MWE_FPC defines as above and renamed it to "aname" and it compiles fine. Is this a possible bug in the compiler, or is it a bug in Delphi that allows it?

The second problem is in the implementation of the Add method above. The following line

    Datas[crc][DatasUsed[crc]]:= Value;

causes the following compiler error

Incompatible types: got "TSPEEDLISTOBJECT" expected "TSPEEDLISTOBJECTS"

It looks to me like it is trying to do some sort of two dimensional array or something. I don't understand what this is doing, so I don't know how to fix it. Can someone explain what this is doing and how I an fix it to work in FPC?

Again, if you don't understand my message, just try compiling the cbUtils.pas unit in the mwEdit directory. I am committing the changes I have made to CVS so it will have the same code I am working on.

Curtis

See you have been a little busy also... I guess it is time for me to go home and kickit up a notch now.

Is it going to snow this weekend like they are talking Shane. I hope it snows like hell this winter' I got my snowmobiles rebuilt and ready to go.

Cliff

Hi,

I'm new to this mailing list, but from my experience with Delphi I think I can answer the first question...

In Delphi the "name" parameter takes preference over the property because the scope rules state that a
parameter or local variable takes preference over
class properties or member variables. FPC should be allowing this to compile and you would then use
self.name inside the procedure to reference the
property. HTH.

BTW, I was browsing the web site and have been waiting for it to be updated and it hasn't been for a while...

Cheers,
Kevin.

=====

__________________________________________________ Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Updated CVS again. Added the TLMLButtonDown messsages and procedures to handle them. Updated a lot of other things too but it's been a tough day so I don't remember them. :-)

All I did was add compatability again today. We are getting closer........it may not DO anything, but it will soon compile!

Shane

>> Curtis White 10/20/99 10:28PM >>>

Yes, you are right. I am working with the beta version. I figured that our code isn't beyond beta and by the time we get it working, it will probably be a release version. Since the beta will be closer to the release version, I thought it would be easier to get from there to the next version than from the release version. But if you all think we should use the release version, that is fine with me. Like you, I would just like to get an editor going soon. I think that will help motivate more people to help.

Curtis

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

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

I came upon two problems in the cbUtils unit when working to compile mwEdit that I don't know exactly how to fix. I don't know if they are compiler bugs or something else. Can someone take a look at the following and tell me how I can fix it for FPC?

In the cbUtils unit, are the following definitions:

  TSpeedListObject = class
  protected
    FName: String;
    FSpeedList: TSpeedStringList;
    procedure SetName(const Value: String); virtual;
  public
    Property Name: String read FName write SetName;
    {$IFDEF MWE_FPC}
    constructor create(aname: string);
    {$ELSE}
    constructor create(name: string);
    {$ENDIF}
    destructor destroy; override;
    property SpeedList: TSpeedStringList read FSpeedList write FSpeedList;
  end;
  PSpeedListObjects = ^TSpeedListObjects;
  TSpeedListObjects = array [0..0] of TSpeedListObject;
  TSpeedStringList = class
  private
    function GetText: string;
    procedure SetText(const Value: string);
  Protected
    FOnChange: TNotifyEvent;
    SumOfUsed: array [0..NbSubList-1] of integer;
    datasUsed: array [0..NbSubList-1] of integer;
    datas: array [0..NbSubList-1] of PSpeedListObjects;
    lengthDatas: array [0..NbSubList-1] of integer;
    procedure Changed; virtual;
    function Get(Index: Integer): string; virtual;
    function GetObject(Index: Integer): TSpeedListObject;
    function GetCount: integer;
    Function GetStringList: TStrings;
    Procedure SetStringList(const value: TStrings);
  public
    Procedure NameChange(const obj: TSpeedListObject; const NewName: String);
    Procedure ObjectDeleted(const obj: TSpeedListObject);
    destructor Destroy; override;
    constructor create;
    function Add(const Value: TSpeedListObject): Integer;
    procedure Clear;
    function Find(const name: String): TSpeedListObject;
    property OnChange: TNotifyEvent read FOnChange write FOnChange;
    property Objects[Index: Integer]: TSpeedListObject read GetObject;
    property Strings[Index: Integer]: string read Get; default;
    property count: integer read GetCount;
    Property StringList: TStrings read GetStringList write SetStringList;
    property text: string read GetText write SetText;
  end;

Then the function below implements the Add function.

function TSpeedStringList.Add(const Value: TSpeedListObject): Integer;
var
  crc: integer;
  i: integer;
begin
  crc:= StringCrc(Value.Name) mod (High(Datas)+1);
  if DatasUsed[crc]=lengthDatas[crc] then begin
    {$IFDEF MWE_FPC}
    ReallocMem(datas[crc], DatasUsed[crc],
(lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ELSE}
    ReallocMem(datas[crc], (lengthDatas[crc]*2+1)*SizeOf(datas[1][0]));
    {$ENDIF}
    lengthDatas[crc] := lengthDatas[crc]*2+1;
  end;
  Datas[crc][DatasUsed[crc]]:= Value;
  result:= SumOfUsed[crc]+DatasUsed[crc];
  inc(DatasUsed[crc]);
  for i:= crc+1 to High(SumOfUsed) do
    inc(SumOfUsed[i]);
  Value.SpeedList:= Self;
end;

The first problem I had was in the constructor of the TSpeedListObject. It passes in a parameter called "name". There is also a property called name. When I tried to compile this, it had a problem because the compiler confused the parameter with the property and gave me an error stating that Name was already defined. I put in the MWE_FPC defines as above and renamed it to "aname" and it compiles fine. Is this a possible bug in the compiler, or is it a bug in Delphi that allows it?

The second problem is in the implementation of the Add method above. The following line

    Datas[crc][DatasUsed[crc]]:= Value;

causes the following compiler error

Incompatible types: got "TSPEEDLISTOBJECT" expected "TSPEEDLISTOBJECTS"

It looks to me like it is trying to do some sort of two dimensional array or something. I don't understand what this is doing, so I don't know how to fix it. Can someone explain what this is doing and how I an fix it to work in FPC?

Again, if you don't understand my message, just try compiling the cbUtils.pas unit in the mwEdit directory. I am committing the changes I have made to CVS so it will have the same code I am working on.

Curtis

I took the release code that Shane has been working on and worked on it some tonight to get it to compile. I am down to the last unit. All the units are compiling now except the mwcustomedit.pas and it is close. I will have it compiling by tomorrow. Once I get that one compiled, I will finish working to get the beta version to compile. Then it will just be a matter of implementing the code that was making calls to Windows functions and a few other things that we haven't completed in FPC and LCL yet (like the registry). But there are quite a few calls to Windows functions that we are going to have to come up with a way to do with GTK. So it is still going to take a bit of work to get it completely working. But we are getting closer :-)

Anyway, I created a directory for this code in CVS. It is in the components/mwedit directory. The directory is called "release" (components/mwedit/release). I also included a makefile to compile it.

In this release version, instead of using the MWE_LAZ_FIX_LATER define, I have just been including comments that explain what needs to be done. Each of these comments is prefixed with "TODO:". So you can just do a grep for TODO: to find out what all changes need to be done. Anyone feel free to start working on some of those things that need to be done.

Just letting everyone know where to find it and what the status is.

Curtis

OK, I am down to line 4052 but am getting an error when calling ReAllocMem!!!!

I createed a new function in windows.pp but it MUST be looking elsewhere.

Curtis, let me know how far (if anywhere) you get after you update CVS......

We are getting there....

Shane

Why do I need the current size? I should be able to do a sizeof(pointer) to get the size. Actually I don't need to do that because if I am REALLOCating memory, all I need to do is a freemem(pointer) getmem(pointer,newsize) Can we get another reallocmem function added to the rtl? ------------------------------------------------------------ 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
----------------------------------------------------------

Shane Miller wrote

OK, I am down to line 4052 but am getting an error when calling ReAllocMem!!!!

ReAllocMem is part of the RTL. I built the function patterened on the Delphi 1 method. It requires that a size parameter be passed.

Delphi 2, 3, 4, & 5 version of ReAllocMem depend on the memory management feature of Delphi to know how much memory to release. To use the current ReAllocMem you need to be sure to call it like this:

procedure ReAllocMem(var P: Pointer; currentSize: longint; newSize:
longint);

Maybe -vb helps?

Yes. And to get the size of a memoryblock you can use MemSize(pointer). I still want to add the Reallocmem also to the heap manager to make a less fragmenting function of it.

Peter

Shane Miller wrote

Why do I need the current size? I should be able to do a sizeof(pointer) to get the size.

That will give you the size of a pointer. Not the size of the area the pointer is pointing to. :-\

Unless you use the memory manager found in Delphi 2 and up your have know way of knowning how much memory is associated with a pointer to a memory location. You have to tell it how much memory it is associated with.

Actually I don't need to do that because if I am REALLOCating memory, all I need to do is a freemem(pointer) getmem(pointer,newsize)

This is how the current ReAllocMem works and what can be passed to it. As I said this is a direct match to Delphi 1.

1. if P is nil and newSize is zero do nothing
2. if P is nil and newSize is NOT zero allocate memory and clear it to 0
3. if P is NOT nil and newSize is NOT zero a new memory block allocated the data is copied from the old block to the new block and the old block is disposed of.

if P is NOT nil then currentSize must be the size used to allocate memory for P whether it was using AllocMem or ReAllocMem.

procedure ReAllocMem(var P: Pointer; currentSize: longint; newSize:
longint);

Can we get another reallocmem function added to the rtl?

Unless a memory management scheme is used for AllocMem and ReAllocMem that will maintain a record of allocated space for memory blocks when using these routines you will have to pass the current size of the existing allocated memory.

Since ReAllocMem was written I have seen some notes that indicate that Peter might have added some heap management that will allow you to do a freemem(pointer) without suppling the size of the memory block. If that is the case we can of course change ReAllocMem to use this form of FreeMem and hopefully be able to identify the size of the block for the copy block function.

Peter is that the case????

On 25-Oct-99 Shane Miller wrote

OK, I am down to line 4052 but am getting an error when calling ReAllocMem!!!!

With all the ReAllocMem function calls, I have been adding IFDEFs and passing the 3 parameters. You have to pass the current size of the allocated memory in FPC. I figure we can remove them as soon as this is fixed in FPC. But at least it will allow it to compile now.

I createed a new function in windows.pp but it MUST be looking elsewhere. Curtis, let me know how far (if anywhere) you get after you update CVS......

Actually, I have updated CVS with the latest version that I have. I added a directory in components/mwedit called "release" (components/mwedit/release) and have put the latest version of the release files I have in there. I have almost the whole release version compiling now. There is only one unit left to finish and that is the mwcustomedit.pas unit. I also have most of that one compiling. But there are still quite a few things in it to fix. It is a huge unit.

Since I created a new directory, nobody will probably be able to access it until Michael, or someone, changes the priviliges. Can someone fix the priviliges of the release directory (there are also 2 directories inside it) and files inside components/mwedit?

We are getting there....

Yep. We are very close to getting it to compile now. But there are a fair amount of things to implement before it will work.

You know, I was thinking about something concerning mwEdit. I think we should let the people who have been developing it know that we are working to get it to compile with FPC for Lazarus. If they know that, they might be a little more careful about calling Windows functions and doing other things that might not be compatible. Just an idea.

I am still looking forward to getting the SHEdit component working. I think we can get it working pretty fast as soon as Sebastian gets it fixed and gets that abstract class created.

Curtis