Correct. I placed it in gtkint.pp which contains all the GTK stuff.

Shane

>> 07/06 3:32 PM >>>

Once more, I don't think that this belongs in the TControl Class. It is gui dependent; so it must go in guiapi (or whatever you called it)

If I understood correctly, TControl is GUI independent; so it should not have the DoDispatchStr().

But then I haven't seen any of your code :( so I cannot really tell. Just some theoretical rambling here...

Michael.

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

The trick to this is do NOT put the guiapi unit in the uses clause at the beginning of the program. Place a second uses clauses just before the code starts. Dang I forget the terms. Is it interface? I have to wait until I get home to look at some code. When you place the unit at this location it doesn't create the circular reference.

The reason it needs to call it is because the SetName opr SetCaption procedures in TCOntrol need to call it along with TCOntrol's resize function and a few others.

Just move the guiapi to the correct location. Oh I know. Look in the forms.pp file that I sent you. It shows you were to place the

   uses guiapi;

line so that it works correctly.

Before getting into any other reasons, can we find a way to get this to work without guiapp inheriting tcontrol?

The above fixes it. :-)

Shane Miller wrote

Where are you located?

North East Pa. - WilkesBarre-Scranton area.

I'd like to get a chat going between you , Cliff and I either over the net or on the phone.

No problem. It is about 2:52 PM here and I will be heading home from this current job at 3:00 PM we can talk after 4:00PM.

I see now how you plan on implementing the messages. I finally understand, I think, how you plan on implementing the envents and such, but the need for TControl to call guiapp is going to mess us up alot.

declare the "uses guiapi" in the correct location as indicated in previous email. :-)

Talk at you later,

Shane Miller wrote

I'll take it and include it with Lazarus for now.

It really should be included as part of the FCL. I just wrote it this weekend so I didn't get around to sending to mvc to see about including it. MVC your on this list shouldn't this be in the basic FCL stuff?

Send me your phone # to

>> "Michael A. Hess" 07/06 3:09 PM >>>

Just create another method in TControl called

procedure TControl.DoDispatchStr(message : string)
begin
   DispatchStr(message);
end;

The reason I did it this way is because I was thinking that maybe it could be used then as a way to send messages to other controls. Maybe it is from the dept. of reducancy dept. but hey, I was coding on the fly and as you noticed and as I mentioned somethings weren't totally done yet. :-)

What I sent you was just to give you and idea of what I was doing and not to really start to implement it yet. However, it appears that you are starting to add it in so that's OK with me. :-)

What point are you at? Are you going to commit stuff to CVS so that I can help with coding some of the CVS code?

By the way Shane I am back in my own office now so we can have a phone conversation anytime the rest of the evening. :-)

Shane Miller wrote

Correct. I placed it in gtkint.pp which contains all the GTK stuff.

Then you don't need DoDispatchStr just call DispatchStr directly.

Since I am going to stick mainly to Win32 until I get RH6 up, and where I know my way around a bit better, I would veru much like this, as writing to the console in a window slows things down terribly.

Jeff.

*********** REPLY PARTITION ***********

It is debatable. In my opinion, one of the first enhancements you should make is that it should be able to open a window with a memo, and display the text in that, together with a copy in a file.
Then it should be part of lazarus...

So I think you should do the following:

TDebug; <- Your current implementation (enhanced maybe) TGUIDebug; <- Enhancement to display in a window as well. (additional Property WindowVisible and methods
ShowWindow, HideWindow. Window should have buttons 'Hide','Debug off')

The TDebug can go in the FCL, TGUIdebug should go in Lazarus. If you agree on this, then the TDebug can go in FCL, TGUIDebug can go in Lazarus.

The only problem with this Debug object (in my eyes) is that it makes your program bigger and slower. {$ifdef}ed code simply isn't there if you don't want it. Also, the Assert() construct of Delphi is implemented in the compiler since a long time, why not use that one as well?

What do you think about the above enhancements?

Michael.

Where are you located? I'd like to get a chat going between you , Cliff and I either over the net or on the phone. I see now how you plan on implementing the messages. I finally understand, I think, how you plan on implementing the envents and such, but the need for TControl to call guiapp is going to mess us up alot.

Can we connect somehow so we can chat. I'd like to get this worked out.

Shane

Once more, I don't think that this belongs in the TControl Class. It is gui dependent; so it must go in guiapi (or whatever you called it)

If I understood correctly, TControl is GUI independent; so it should not have the DoDispatchStr().

But then I haven't seen any of your code :( so I cannot really tell. Just some theoretical rambling here...

Michael.

I know that the code wasn't finished. Just had a few questions about it. I like to try stuff.

I am about done implementing your stuff into my code. Have a few compiler errors to work out. If it works, and the events get pushed around like I expect, and the IDE (what there is of it) comes up like I expect it to then I will commit the new source, otherwise I will work on it tomorrow yet.

Shane

>> "Michael A. Hess" 07/06 3:09 PM >>>

Just create another method in TControl called

procedure TControl.DoDispatchStr(message : string)
begin
   DispatchStr(message);
end;

The reason I did it this way is because I was thinking that maybe it could be used then as a way to send messages to other controls. Maybe it is from the dept. of reducancy dept. but hey, I was coding on the fly and as you noticed and as I mentioned somethings weren't totally done yet. :-)

What I sent you was just to give you and idea of what I was doing and not to really start to implement it yet. However, it appears that you are starting to add it in so that's OK with me. :-)

What point are you at? Are you going to commit stuff to CVS so that I can help with coding some of the CVS code?

By the way Shane I am back in my own office now so we can have a phone conversation anytime the rest of the evening. :-)

One question yet. OK, I can put uses guiapp in the implementation portion of TControl.

Where is DoDispatchStr supposed to be? I know someone replied saying it should be in guiapp but then why the calling convention TControl(data).DoDispatchStr? Should it be TObject(data).DispatchStr();? Why notr just call TObject's dispatchStr from here?

Shane

>> "Michael A. Hess" 07/06 1:48 PM >>>

Shane Miller wrote

Where are you located?

North East Pa. - WilkesBarre-Scranton area.

I'd like to get a chat going between you , Cliff and I either over the net or on the phone.

No problem. It is about 2:52 PM here and I will be heading home from this current job at 3:00 PM we can talk after 4:00PM.

I see now how you plan on implementing the messages. I finally understand, I think, how you plan on implementing the envents and such, but the need for TControl to call guiapp is going to mess us up alot.

declare the "uses guiapi" in the correct location as indicated in previous email. :-)

Talk at you later,

Just create another method in TControl called

procedure TControl.DoDispatchStr(message : string)
begin
   DispatchStr(message);
end;

The reason I did it this way is because I was thinking that maybe it could be used then as a way to send messages to other controls. Maybe it is from the dept. of reducancy dept. but hey, I was coding on the fly and as you noticed and as I mentioned somethings weren't totally done yet. :-)

What I sent you was just to give you and idea of what I was doing and not to really start to implement it yet. However, it appears that you are starting to add it in so that's OK with me. :-)

What point are you at? Are you going to commit stuff to CVS so that I can help with coding some of the CVS code?

By the way Shane I am back in my own office now so we can have a phone conversation anytime the rest of the evening. :-)

Greetings,

I have also created a Debug class for use in a FCL based project.

It is a class called TDebug.

It has the following methods:

   Write(message : string);

and the following properties:

LogFile : String
DebugOn : Boolean

It is a simple thing to use. All you have to do is include it in the file that you want to have debug output. It is does a self setup so you don't have to creat anything.

Just add udebug to your uses clause.

Then set

  Debug.DebugOn := True;

and from then on anything that calls

  Debug.Write('your message');

will get output.

If you don't specify a LogFile then all out put goes to the console. If you do specify a LogFile:

  Debug.LogFile := 'project.log';

Then all output goes to the file projects.log. This way you can easily use it for console output during development and for an error log in the actual program.

When you don't want any of the output just don't set DebugOn to True. It is a lot cleaner then a whole lot of #ifdefs.

OK. Any want it?

I'll take it and include it with Lazarus for now.

Shane

The 'DoDispatchStr()' should be in GUIApp, NOT in TControl... Don't forget that the DispatchStr() is added for GTK only !

For Win32 native apps, for instance, you will need the Dispatch method. So the GUIApp from Win32 would have A DoDispatch instead of a DoDispatchStr.

I *hope* this solves the problem, since Dispatchstr() is in TObject, as well as Dispatch.

Michael (V.C).

The 'DoDispatchStr()' should be in GUIApp, NOT in TControl... Don't forget that the DispatchStr() is added for GTK only !

DoDispatchStr is NOT in guiapp so I guess that's why I was confused. You are calling it like TControl(data).DoDispatchStr(message) so I'm not sure why you are doing that then.....

I will add that function. I assume is simply calls TObject's dispatchStr?

Shane

Michael,

I was adding your code into my Lazarus code to see how it is going to work. I like pretty much everything that you did so I figured I'd implement it and see how it works. I ran into a problem.

Your GUIAPP inherits from TCOntrol. I assume this is because you need to typecast the 'self' sender as a tcontrol to call dodispatchstr. Problem is that won't work. Reason is because TControl needs to call guiapp and if it inherits that class, then there will be a circular reference.

The reason it needs to call it is because the SetName opr SetCaption procedures in TCOntrol need to call it along with TCOntrol's resize function and a few others.

Before getting into any other reasons, can we find a way to get this to work without guiapp inheriting tcontrol? I have a few other problems that I foujnd that this will cause and if we can fix this it'll be a big help.

Does it NEED to typecast them as a TCOntrol or can it use TObject?

Shane

>> Michael Van Canneyt 07/06 2:20 AM >>>

It is debatable. In my opinion, one of the first enhancements you should make is that it should be able to open a window with a memo, and display the text in that, together with a copy in a file.
Then it should be part of lazarus...

So I think you should do the following:

TDebug; <- Your current implementation (enhanced maybe) TGUIDebug; <- Enhancement to display in a window as well. (additional Property WindowVisible and methods
ShowWindow, HideWindow. Window should have buttons 'Hide','Debug off')

The TDebug can go in the FCL, TGUIdebug should go in Lazarus. If you agree on this, then the TDebug can go in FCL, TGUIDebug can go in Lazarus.

The only problem with this Debug object (in my eyes) is that it makes your program bigger and slower. {$ifdef}ed code simply isn't there if you don't want it. Also, the Assert() construct of Delphi is implemented in the compiler since a long time, why not use that one as well?

What do you think about the above enhancements?

Michael.

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

It still is GUI independent. I don't see how the above code ties it in any way to the GUI be that GTK or Qt or whatever. Instead of calling TControl.DispatchStr directly it just calls TControls.DoDispatchStr. I can't see how that makes much of a difference. Am I missing something?

Well, for a Win32 widget it wouldn't make sense to call dodispatchstr(). If it isn't in TControl, it can't be called, so we avoid mistakes :-)

Just a matter of clean coding.

Michael VC.