Thanx I will look at implementing that I am having a hell of a fight with resize and stuff at the moment. I checked out the cvs source code and lost the menus. Now when I do a resize I get blow out of the water not cool.

Cliff

OK,
�
I've been lurking around and I just d/l'd the Win32 installer and installed it...� Installation went smooth!� Fine, and good.
�
However, I fired up Lazarus and got the IDE and was wondering if there is way to accomplish three things?
�
First,� What flags do I have to set to turn off seeing all those DOS Command Prompt messages when firing up Larazus.exe? (And also to not see same messages for every button click?
�
Second, I can Open and Save a file, but I seem not to get any editor when selecting New?� (This applies to other menu choices as well, such as New Project.)
�
Third, Once I have written and saved source changes, *HOW* do I invoke the compiler from the IDE menu bar?!?
�
Derek A Benner"I am a Linux Newbie...� That's equal to a WinNT Master and an iMacGURU!"

I agree, but the only problem with using the Debug class is that it compiles extra code into your programs, even when you turn Debug off. Maybe we should wrap the calls to the Debug class in ifdef DEBUG directives and include the define DEBUG in the Debug unit file. Then all we have to do is comment out the define and recompile and all the debug code will get compiled out. This gives us the ability to use the logging that the Debug class provides and still allows us to compile out the code when we are done debugging.

Just an idea.

Curtis

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

That is very true. That would be a very nice option to have. But I think we should allow the person developing with Lazarus the ability to decide if they want the extra code or not. If we wrap all calls to the Debug class in an ifdef DEBUG that is defined in the Debug class, then in Lazarus, we could provide a Project Options swich that would either define or undefine the DEBUG directive and would either compile in or not compile in the code. This allows complete flexibility and doesn't force the developer to have a bunch of Debug code in their program that they don't want.

Suppose there is a bunch of Debug code in each class used in Lazarus. Then someone comes along and builds an app with it. Their program would probably be much larger because of all the debug code. That is the kind of thing that causes programs to be bloated and large and the end developer has no choice. If you were developing a commercial program with Lazarus, would you want a bunch of debug code, that you didn't put there, in your program that you are selling? Personally, I would want the option to not have it.

This also allows us the flexibility to temporarily compile debug code ONLY into a specific unit by putting a {$DEFINE DEBUG} at the top of that unit and then undefining it in the Debug unit. Then all the debug code could be compiled out except in that one unit. It just allows us a lot of flexibility.

Curtis

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

Michael A. Hess wrote

When we use it we just need to add the udebug unit to the lazarus.pp code and in that unit we can then turn on or turn off ALL debugging for all of the files. As MVC suggested we can then expand on this to have it add output to a window in the IDE.

Also, this should allow for turning on debug for a short section of code, then turning it back off, which should make it easier to find bugs that occur because of things like race conditions and so forth.

Jeff

P.S. "... and so forth." reminds me, has anyone ever attempted a RAD environment for Forth? Now there is a language which was almost taylor made for event driven programming. Even though it is one of those things that has all of the dangers of C and all of the readability of Hungarian translated to Japanese then to English ;^)

This brings up a good point I started to put in a bunch of ifdef DEBUG but does that make sense or should we build a object based on tstrings that can print the debug list to a file or the screen for debugging or shutting it off all together...

Cliff

Well some can be turned off and some can't. Right now this is in real rough development so there is ALOT of tracing statements so that we can see what exactly is going on when we add code. In short order some of this will start to get cleaned out as we are satisified that the code works as it should. Be patient just a little more and those kind of things will disappear.

Second, I can Open and Save a file, but I seem not to get any editor when selecting New? (This applies to other menu choices as well, such as New Project.)

This code hasn't been added yet.

Third, Once I have written and saved source changes, *HOW* do I invoke the compiler from the IDE menu bar?!?

Again this code hasn't been fully implemented yet.

We have redirected some of the work for the moment from the IDE to more components that the IDE needs. In short order things will start to come together.

Curtis White wrote

I agree, but the only problem with using the Debug class is that it compiles extra code into your programs, even when you turn Debug off.

True but I LIKE this. Just think you can add this to the code and have it turned off. Then if the user is having problems with the program you can have them use a command line options to turn on the debugging and give you a detail report of what the program is doing.

We can certainly add more features and functions to the class so that it can turn on only certain sections, or all sections, app level code, or system class library code, etc. etc. etc. Allows for debuging after delivery. I think that is worth the little bit that it adds to the project. The way it is designed you add the unit to each of the units where you want to use it. But there is only every ONE instance of the debug created so it really isn't adding that much to the application.

Cliff Baeseman wrote

This brings up a good point I started to put in a bunch of ifdef DEBUG but does that make sense or should we build a object based on tstrings that can print the debug list to a file or the screen for debugging or shutting it off all together...

Why don't you use Michael Hess' debug object he posted some time ago ? With minimal effort , the debug can be sent to a window with a tmemo in it if required.

Michael.

Yep I agree Curtis... That would probably be a good idea...

Cliff

Why don't you use Michael Hess' debug object he posted some time ago ? With minimal effort , the debug can be sent to a window with a tmemo in it if required.

Here is the post again so you don't have to go look for it. As stated it is simple to use. Cliff either you or I can commit this to CVS. Take your pick.

When we use it we just need to add the udebug unit to the lazarus.pp code and in that unit we can then turn on or turn off ALL debugging for all of the files. As MVC suggested we can then expand on this to have it add output to a window in the IDE.

Here it is. It is plainfully simple. Just use it as follows. Place it in the uses clause in the unit where you want to use it.

   uses udebug;

Then someplace in the unit just turn on debug output with.

   Debug.DebugOn := True;

Now any place you have the text

   Debug.Write('my message');

you will get that output. As I stated if you want it to go to a log file then add

   Debug.LogFile := 'mylogfile.log';

The rest takes care of itself.

+++++++++++++++++++++++++++++++++++++++++++++
unit udebug;
{$mode delphi}
interface
uses sysutils;
type
   TDebug = class
   private
      { Private declarations }
      fLogFileName : string;
      fState : Boolean;
   public
      { Public declarations }
      constructor Create;
      procedure Write(message : string);
      property LogFile : String read fLogFileName write fLogFileName;
      property DebugOn : Boolean read fState write fState;
   end;
var
   Debug : TDebug;
implementation
constructor TDebug.Create;
begin
   fLogFileName := '';
   fState := False;   { False is off - True is on }
end;
procedure TDebug.Write(message : string);
var
   fileH  : Text;
begin
   if fState then
   begin
      Assign(fileH, fLogFileName);
      {$I-}
      if fLogFileName  '' then
         if FileExists(fLogFileName) = False then
         begin
            Rewrite(fileH);
            Close(fileH);
         end;
      Append(fileH);
      if ioresult = 0 then
         Writeln(fileH, message);
      {$I+}
      Close(fileH);
   end;
end;
initialization
   Debug := TDebug.Create;
finalization
   Debug.Free;
end.

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

yep that is what i was referring to..

Cliff

I like it, especially since even if this is done, you are free to do the following...

Procedure TMyObject.DoSomething;
Var SomeVar: Integer;
Begin
 ....
debug.write('testing');
...
end;

... so that you don't have to go changing compiler options just to debug one routine, and you don't have to see everything in the whole app either.

Jeff.

Michael Van Canneyt wrote

Exact. But I am not sure whether the parser supports {$DEFINE DEBUG:=//} the // comment may confuse it. Has this been tested ?

It works like a charm here is how I set it up.

program test;
{$define DEBUGOUT:=//}
begin
   writeln('first line');
   DEBUGOUT ('*** debug line ***');
   writeln('last line');
end.

When done this way I only get the 2 writeln statements. When I changed it to this.

program test;
{$define DEBUGOUT:=writeln}
begin
   writeln('first line');
   DEBUGOUT ('*** debug line ***');
   writeln('last line');
end.

I get all 3 lines. Works cool.

I had hoped I could do something like this.

{$define //DEBUGOUT:=writeln}

begin
.
.

   //DEBUGOUT ('debug text');

.
.
end.

This way if the macro wasn't defined or if -Sm was set it would just take the line as a comment. Infortunately it doesn't appear that the define statement can handle a macro named with leading '//' characters.

Hey compiler guys any chance that this is changable? That would make the code really slick if it could be self commenting lines.

This is what the TDebug class does already without the need of IFDefs. The switch that sets debug on or off is just a flag that tells the TDebug.Write to do a direct return and not do anything. The ifdef wouldn't buy you anything.

2. Use the macro feature of fpc

NOW THIS IDEA I LIKE!

Here is what we could do.

{$define DEBUGOUT:=debug.write}

Then anyplace in the code put code

DEBUGOUT ('whatever trace information you want');

Then when you don't want debug you just need to redefine the macro to be

{$define DEBUGOUT:=//}

The the code becomes

// ('whatever trace information you want');

What does everyone think about this???

Cliff wrote

I really like that idea...

Cliff you mentioned before that you were going to work on setting some of the debug stuff. Do you want to try and set this up and see if it will work or do you want me to try it out. I'm not sure how we will get it all tied together but we need to test it to see if it works first.

Peter Vreman wrote

But macro's doesn't support parameters.

It doesn't have to to do what we are suggesting.

Curtis White wrote

Can we create a directory specifically for the component development separate from the Lazarus code. They really shouldn't be mixed like they are. It will just confuse people (especially me).

I agree. There really is two parts to what we are doing. The work on the class libraries is really intended to be part of the FCL while the IDE is what is actually Lazarus. At this point in trying to build Lazarus we are creating the class libraries but they are not part of the IDE. They will just be used to MAKE the IDE. Think of it this way you can write any application to use the class libraries, which has been done - the test program, hello_world, without the need of Lazarus.

I think it is time we start separating the 2. We need to have a directory setup that just builds the PPUs for the class libraries and then another directory for actual development and testing work.

Cliff since you are adding the debug stuff and the .inc separation why don't you do this at the same time. It is just a matter of creating another directory for just the IDE code and creating a new makefile. Let's do it now before it does get to much more complicated.

Nope I do not wish for them to change the compiler for anything whatsoever.

It's running to darn good to break it now. Not once have I had any compiler problems in the
last couple of weeks ;)

Ship version 1 now!

Cliff

Just as an aside..
I use a byte in the debug routine, for a debug level. This may or may not be worth looking at....
Along with the Macro Idea..
Maybe with IfDefs ?

Program DebugTest;
Const
	DebugLevel = 2;
Procedure PDebug(InLevel : Byte; InString : String);
Begin
If InLevel >= DebugLevel then
	Writeln(InString);
End;
Begin
PDebug(1,'General Debug Message');
PDebug(2,'More Serious Debug Message');
PDebug(100,'Stupidly Verbose Debug Message');
End.

Brad....

"Where do YOU want Microsoft to go today"
"Why pay for a broken OS, when you can get one that works for free ?"

/"\
\ /
X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
/ \

But macro's doesn't support parameters.

Peter

I will do this while moving the stuff to .inc files. I am going to start with forms first. I plan on breaking out each class into its own .inc. Should the headers be seperated also?

Cliff

Hey everyone, the Lazarus directory is really getting a lot of stuff in it. It is getting confusing what files are part of the IDE and what files are part of thecomponent code. Can we create a directory specifically for the component development separate from the Lazarus code. They really shouldn't be mixed like they are. It will just confuse people (especially me).

Also, if we are going to use the Debug class as part of our regular development, we should probably check it into CVS along with the rest of the component code. That way we are all working off the same Debug class.

Curtis

Cliff wrote

I really like that idea...

The other cool thing about it is that you can use a different macro name in different places or different leaves of code so that when you set that macro you only turn on certain debugging.

SYSDEBUG ('xxxxxxx');
GTKDEBUG ('xxxxxxx');
USERDEBUG ('xxxxxxx');
APPDEBUG ('xxxxxxx');

The developer can make as many or as few as they wish and they will only be in the code if the macro is set. This is neat. :-)

With the {$if ...} condition statement we can even exclude the udebug unit from the form completely.

Then we should also allow things like

{$define {:=hello}

Do you really want to make a mess with such macro's?

// is comment and is parsed like that. The macro's are only replaced after
a identifier is read.

Peter

I really like that idea...
Cliff

Exact. But I am not sure whether the parser supports {$DEFINE DEBUG:=//}
the // comment may confuse it. Has this been tested ?

Michael.

Michael Van Canneyt wrote

Exact. But I am not sure whether the parser supports {$DEFINE DEBUG:=//} the // comment may confuse it. Has this been tested ?

That is why I asked Cliff to test it. I might give it a try here in a few minutes and post the results.

Excellent idea. I forgot all about the macro features of the compiler. Sheesh, that provides a lot of power and flexibility. This is really good. This has my vote.

Curtis

Hi!

I agree that the extra code for the debug isn't nice but I really hate to have many "ifdef's" in the code. From my point of view there are 2 solutions:

1. Let's live with the extra code and put the ifdef's only in the debug-class. This would give some extra code, but the cost would only be an extra call with a direct return. When thinking of performance this approach should be OK.

2. Use the macro feature of fpc and use something like "DEBUGOUT" instead of a direct call to the debug class.
I don't know much about the macro facility in fpc but if it's as powerful as in C this shoul work. (Personally I don't like to see such features in fpc-code but who cares...)

bye,

Stefan

Hi!

I'd like to see an extra directory with examples for the different components. The way the GTK team did it seems good:

|
+examples
|-- Makefile
|-- README.1ST
|-- checkbox
| |-- Makefile
| -- checkbox.pp
|
|-- button
| |-- Makefile
| -- button.pp
|

This would offer a starting point for new users and can help us during development because it allows to test each component without running into bugs burried in some other component.

bye,

Stefan

I agree with peter on this.

In any case, I think the possibility of using assert is better.

Michael.

No your right this would open up to many possibilities of creating a real hair ball in the code and since it only replaces it after the fact it would be tough figure out what is actually going on.

It was just a thought for discussion. Which is dropped. ;-)

Besides I think we'll go the Assertion route. It is probably the cleanest and easiest to implement. I'll recode the udebug tonight.

Hi!

Cliff Baeseman wrote

I will do this while moving the stuff to .inc files. I am going to start with forms first. I plan on breaking out each class into its own .inc. Should the headers be seperated also?

I'm not sure about this because it suggests a separate header file and I'd really hate to see this C-ish approach.

Hmm, what about the following:

---- file: stdctrls.pp

Unit stdctrls;
INTERFACE
{$define INCLUDE_INTERFACE}
	{$i checkbox.inc}
{$undef  INCLUDE_INTERFACE}
IMPLEMENTATION
{$define  INCLUDE_IMPLEMETATION}
	{$i checkbox.inc}
{$undef  INCLUDE_IMPLEMETATION}
end.

---- file: checkbox.inc

{$ifdef INCLUDE_INTERFACE}
	TCheckBox = class
	public
	  constructor Create (AOwner : TObject);
	end;
{$else}
   {$ifdef INCLUDE_IMPLEMENTATION}
	constructor TCheckBox.Create (AOwner : TObject);
	begin
	end;
   {$endif}
{$endif}
----

bye,

Stefan

I will do this...

Cliff

Yes I agree also because you can just open up one unit and see all of the class definitions.

Cliff