Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-11

mwEditCustom bug killed

20 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Shane Miller

YAHOO! 2 Versions? Not sure...
------------------------------------------------------------ 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
----------------------------------------------------------

Earlier message 19 lines
-----Original Message----- From: Peter Vreman To: Date: Thursday, November 04, 1999 4:11 PM Subject: [lazarus] mwEditCustom bug killed >The bug with 'inherited property' has been killed. Now a lot of $ifndef >FPC's can be removed. > >btw. why are there 2 versions of mwedit? > >Peter > >_________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.miraclec.com/list_archives/lazarus >

Reply by email

Peter Vreman
to Kevin Berry: I agree. Couldn't there be some kind of command line switch that would turn the "delphi…
Show quoted text 5 lines
I agree. Couldn't there be some kind of command line switch that would turn the "delphi compatibility" option on or off. That way you can compile source using the "stricter" compiler settings if you wanted to.

It already exists -Sd or {$mode delphi}

Unit aliases would be important for migrating existing apps.

The code is placed in an ifdef so it's not completly removed yet.

Peter

Reply by email

Kevin Berry

I agree. Couldn't there be some kind of command line switch that would turn the "delphi compatibility"
option on or off. That way you can compile source using the "stricter" compiler settings if you wanted to. Unit aliases would be important for migrating existing apps.

Cheers,
Kevin.

--- Marc Weustink wrote 11 lines
At 22:44 04-11-99 +0100, Peter wrote: >btw. I'll remove the unit alias code from the compiler. Florian and Michael >are against it. It's a pity. It could be handy for compatibility Marc

=====

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

Reply by email

Shane Miller

I just updated from CVS and re-cycled the compiler. Everything worked fine and Lazarus compiles fine. I then went to the mwedit/release directory and compiled mwcustomedit and that worked fine too.

I added mwcustomedit to the uses clause in MAIN.PP in the lazarus directory and added a mwedit : TMWCustomEdit in the TFORM1 class of MAIN.PP and tried to compile LAzarus.pp. I constantly get internal error 9999.

Any thoughts? Wnat me to update CVS with the change so you can try it, or coulsd someone just add it to their own MAIN.PP and try it please. Does it crash for everyone?
I'm going to reboot and see if it's a memory thing but I'm not going to hold my breath... Shane

>> "Shane Miller" 11/05/99 06:55AM >>>

Are you referring to the assembling error or something else? Shane

>> Peter Vreman 11/04/99 05:55PM >>>

The bug with 'inherited property' has been killed. Now a lot of $ifndef FPC's can be removed.

btw. why are there 2 versions of mwedit?

Peter

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

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

Reply by email

Shane Miller

Don't compile Lazarus to get the bug, compile lazarus/lcl/components/mwedit/release/mwcustomedit.pas

That's when the assembly error occurs.
Shane

>> Peter Vreman 11/04/99 06:44AM >>>

I can't reproduce the bug with mwCostumEdit with the incorrect assembler generated.

When i compile lazarus i got first 'windows.ppu not found' bugs. After adding unit aliases to the compiler i got some other error in mwEdit

Unit aliases work with -Ua<unit>=<newunit>

Peter

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

Reply by email

Peter Vreman

I can't reproduce the bug with mwCostumEdit with the incorrect assembler generated.

When i compile lazarus i got first 'windows.ppu not found' bugs. After adding unit aliases to the compiler i got some other error in mwEdit

Unit aliases work with -Ua<unit>=<newunit>

Peter

Reply by email

Shane Miller

Are you referring to the assembling error or something else? Shane

>> Peter Vreman 11/04/99 05:55PM >>>

The bug with 'inherited property' has been killed. Now a lot of $ifndef FPC's can be removed.

btw. why are there 2 versions of mwedit?

Peter

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

Reply by email

Marc Weustink
to Shane Miller: Yes, I am not calling the CREATE because it's crashing during the compile, not while I'm…
Show quoted text 14 lines
So it compiled. Great, but didn't link: Linking ./lazarus /mnt/hdc/usr/src/fpc/gtk/gdk.o: In function `GDK_FONT_XFONT': gdk/gdkx.pp:112: undefined reference to `gdk_debug_level' gdk/gdkx.pp:112: undefined reference to `gdk_show_events' gdk/gdkx.pp:112: undefined reference to `gdk_stack_trace' /mnt/hdc/usr/src/fpc/gtk/glib.o: In function `SET_YEAR': glib/glib.pp:1647: undefined reference to `exportfunc' glib/glib.pp:1647: undefined reference to `exportprefix' glib/glib.pp:1647: undefined reference to `exportcache' An error occurred while linking ./lazarus What's this, do I have to upgrade my gtk libs ???

It looks like somewhere the gtkwin define is gone, so some parts are included in ./gtk/glib/glib.pp and ./gtk/gdk/gdkprivate.pp

I just removed the conflicting lines and lazarus links well.

Marc

Reply by email

Shane Miller

Yes, I am not calling the CREATE because it's crashing during the compile, not while I'm running it. I DO have the code in MAIN.PP to call the create, but I'm not getting a changce to run the program....

Here's more info. If I change TControl and the compiler needs to compile that along with mwcustomedit.pas, then it compiles. If I simply change LAZARUS.PP or MAIN.PP then it crashes.

Not a big deal I guess. To get around the problem I just change CONTROLS.PP and it recompiles everything.

So, I added a mwedit1 component to the MAIN.PP file and call it's create. It goes into the create and crashes when it assigns the TTimers ONTIMER event.....odd. Not sure why yet.....but at least I got it to compile so I can look at it....

Shane

>> "Marc Weustink" 11/05/99 09:32AM >>>

+ From: Shane Miller
+
+ I just updated from CVS and re-cycled the compiler.
+ Everything worked fine and Lazarus compiles fine. I then
+ went to the mwedit/release directory and compiled
+ mwcustomedit and that worked fine too.
+
+ I added mwcustomedit to the uses clause in MAIN.PP in the
+ lazarus directory and added a mwedit : TMWCustomEdit in the
+ TFORM1 class of MAIN.PP and tried to compile LAzarus.pp. I
+ constantly get internal error 9999.
+
+ Any thoughts? Wnat me to update CVS with the change so you
+ can try it, or coulsd someone just add it to their own
+ MAIN.PP and try it please.
+ Does it crash for everyone?
+ I'm going to reboot and see if it's a memory thing but I'm
+ not going to hold my breath...
+ Shane

I will try this as soon as I'm home. If I understand it correctly, you only added a reference, and declared a var. You didn't try to call TMWCustomEdit.Create ???

Marc

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

Reply by email

Curtis White
to Shane Miller: YAHOO! 2 Versions? Not sure... ---------------------------------------------------------…

The reason for this was that I was originally working on getting the latest beta version of mwedit to compile. At the same time, Shane was working to get the release version to compile. The release version has less units and was easier to convert, so we checked it in and decided to get it to compile first. But the beta version is closer to the next release of mwedit, so we really should try to get it to compile too. Otherwise, we are going to have to do this all over again with the new version of mwedit. We just wanted to do the release version since it was smaller and we thought we could get it working faster.

Curtis

On 05-Nov-99 Shane Miller wrote 13 lines
YAHOO! 2 Versions? Not sure... ------------------------------------------------------------ Shane Miller >The bug with 'inherited property' has been killed. Now a lot of $ifndef >FPC's can be removed. > >btw. why are there 2 versions of mwedit? > >Peter >

Reply by email

Curtis White
to Peter Vreman: That was a typo, becuase lazarus compiles fine. I tried mwcustomedit which wouldn't…

Actually, I fixed the error by enclosing it in an {$IFNDEF MWE_FPC} block last night and committed it. This allowed it to compile. You can find it by looking for the above IFNDEF line or by looking for "Result := inherited Font". I also added a TODO comment. The function that contains this is the TmwCustomEdit.GetFont function.

If you remove the IFNDEF and try to compile the mwcustomedit.pas unit with the -al switch, you will get the error and the .s file.

Curtis

On 04-Nov-99 Peter Vreman wrote 16 lines
At 20:48 4-11-99 , you wrote: >Don't compile Lazarus to get the bug, compile >lazarus/lcl/components/mwedit/release/mwcustomedit.pas That was a typo, becuase lazarus compiles fine. I tried mwcustomedit which wouldn't compile. There are at least some references to windows unit which all need to be removed. btw. I'll remove the unit alias code from the compiler. Florian and Michael are against it. Peter

Reply by email

Marc Weustink
to Marc Weustink: It looks like somewhere the gtkwin define is gone, so some parts are included in…

Ok, some report on experiences this weekend.
I finally got a compiled lazarus with a reference to mwCustomEdit. You get an internal error on compileing when something is changed in Controls and mwCustomEdit isn't recompiled. Somewhere the dependencies get mixed up if you do just a make. make clean;make works fine.

After runnig lazarus it dumps. This has something to do with the last changes I made. With the introduction of Handle/HandleNeeded/CreateWnd, at least GTK (but I guess GT and WIN also) objects (merely forms) are created when they are needed. So in the Application.Init part, the LCL object structure is created. In Applucation.Run, the GTK/GT/WIN objects are created. This you can see in the debug output.

The reason why lazarus crashes now is that some routines assume the window is already created. Like InvalidateWnd (the reason now). Since the window isn't created yet, a call to invalidate sould do nothing. (The moment the window is created it has (re)drawn itself already ;-)

In the next days I plan to look after these kind of routines to fix them.

Marc

Reply by email

Shane Miller

If you are compiling the right one, there is a {$IFDEEF MWE_FPC} to use a different "uses" clause in the case of compiling with FPC and it should use LCLLinux instead of Windows.pas....
------------------------------------------------------------ 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
----------------------------------------------------------

Earlier message 24 lines
-----Original Message----- From: Peter Vreman To: Date: Thursday, November 04, 1999 3:22 PM Subject: Re: [lazarus] mwEditCustom bug >> >btw. I'll remove the unit alias code from the compiler. Florian and Michael >> >are against it. >> >> It's a pity. It could be handy for compatibility > >But here is the result when i'm trying to compile mwCustomEdit: > >Compiling mwCustomEdit.pas >Fatal: Can't find unit WINDOWS > > >_________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.miraclec.com/list_archives/lazarus >

Reply by email

Marc Weustink
to Shane Miller: I just updated from CVS and re-cycled the compiler. Everything worked fine and Lazarus…

+ From: Shane Miller
+
+ I just updated from CVS and re-cycled the compiler.
+ Everything worked fine and Lazarus compiles fine. I then
+ went to the mwedit/release directory and compiled
+ mwcustomedit and that worked fine too.
+
+ I added mwcustomedit to the uses clause in MAIN.PP in the
+ lazarus directory and added a mwedit : TMWCustomEdit in the
+ TFORM1 class of MAIN.PP and tried to compile LAzarus.pp. I
+ constantly get internal error 9999.
+
+ Any thoughts? Wnat me to update CVS with the change so you
+ can try it, or coulsd someone just add it to their own
+ MAIN.PP and try it please.
+ Does it crash for everyone?
+ I'm going to reboot and see if it's a memory thing but I'm
+ not going to hold my breath...
+ Shane

I will try this as soon as I'm home. If I understand it correctly, you only added a reference, and declared a var. You didn't try to call TMWCustomEdit.Create ???

Marc

Reply by email

Marc Weustink
to Shane Miller: Yes, I am not calling the CREATE because it's crashing during the compile, not while I'm…
Shane wrote
Yes, I am not calling the CREATE because it's crashing during the compile,

not while I'm running it. I DO have the code in MAIN.PP to call the create, but I'm not getting a changce to run the program....

Here's more info. If I change TControl and the compiler needs to compile

that along with mwcustomedit.pas, then it compiles. If I simply change LAZARUS.PP or MAIN.PP then it crashes.

Not a big deal I guess. To get around the problem I just change

CONTROLS.PP and it recompiles everything.

So, I added a mwedit1 component to the MAIN.PP file and call it's create.

It goes into the create and crashes when it assigns the TTimers ONTIMER event.....odd. Not sure why yet.....but at least I got it to compile so I can look at it....

Shane

Hmmm.... strange things happen here. I had to recompile the compiler to get the ReallocMem support.... This intruduced some other nasties.

I tried to make lazarus, after I changed the followeing line in the ./lazarus/Makefile:
NEEDUNITDIR=../fcl/$(OS_TARGET) ../rtl/$(OS_TARGET) ../gtk lcl lcl/components/mwedit/release

So it compiled. Great, but didn't link:

Linking ./lazarus
/mnt/hdc/usr/src/fpc/gtk/gdk.o: In function `GDK_FONT_XFONT': gdk/gdkx.pp:112: undefined reference to `gdk_debug_level' gdk/gdkx.pp:112: undefined reference to `gdk_show_events' gdk/gdkx.pp:112: undefined reference to `gdk_stack_trace' /mnt/hdc/usr/src/fpc/gtk/glib.o: In function `SET_YEAR': glib/glib.pp:1647: undefined reference to `exportfunc' glib/glib.pp:1647: undefined reference to `exportprefix' glib/glib.pp:1647: undefined reference to `exportcache' An error occurred while linking ./lazarus

What's this, do I have to upgrade my gtk libs ???

Marc.

BTW if I do a make again I get an:
 mwcustomedit.pas(31,10) Fatal: Internal error 9999

Great. Line 31 col 10 does not exist.

even without make:

marc:~/fpc/lazarus$ ppc386 lazarus.pp
Target OS: Linux for i386
Compiling lazarus.pp
Panic : Internal compiler error, exiting.
mwcustomedit.pas(31,10) Fatal: Internal error 9999

Reply by email

Curtis White
to Peter Vreman: I can't reproduce the bug with mwCostumEdit with the incorrect assembler generated. When…
On 04-Nov-99 Peter Vreman wrote 9 lines
I can't reproduce the bug with mwCostumEdit with the incorrect assembler generated. When i compile lazarus i got first 'windows.ppu not found' bugs. After adding unit aliases to the compiler i got some other error in mwEdit Unit aliases work with -Ua<unit>=<newunit>

This is very cool. Somehow, I missed this when I went through the FPC documentation. I didn't know FPC could do this. That gives us the unit alias funcitonality that Delphi has. So we can use this to alias the LCLLinux unit with the Windows unit when compiling under Linux. We can also use this with the WinTypes and WinProcs units just like Delphi does. This is great and gives us one more thing to be compatible with Delphi :-)

Curtis

Reply by email