Logging to the message window

Forgive me if this is in the help, but I'm using WriteLn to output debug into the PICED messages window, but the debug disappears from the window very quickly. I was expecting the debug to simply scroll up the window and I could use the slider to view it, but I'm lucky if I get a few lines of debug there before it disappears (really quickly).

Should I be debugging in a different way?

Thanks.

 

The output window gets cleared each time the logic is run, so you only see messages very briefly. You can use the LogMessage function to write a message to the log file. See the Logic Help file, Debugging Programs section, Debugging Support Features topic.

 

"The output gets cleared each time logic is run". Do you mean each time logic in a different module is run, or is it cleared even if a function is called?

I had tried LogMessage and it doesn't compile as it is not supported in PAC project types. I have changed my project type to a Colour CTouch so that I have some debugging facility. Is changing back and forth between PAC and CTouch a bad thing to do ? Actually it's going to be a pain isn't it, because when I convert it to PAC to run it on the hardware, I'll have to manually remove all the LogMessages.

All the solutions for this I can think of don't work, or aren't a clean solution, unless I'm wrong??

1. Conditional compilation to remove LogMessage's - I don't think thats supported

2. Create a single 'DebugText' function that calls LogMessage so there is only one place to remove it - problem is I don't think I can create a DebugText() function with a variable number of parameters, and most of my debug has multiple parameters.

3. Perform a quick Replace of LogMessages() to something PAC friendly to effectively remove them - the current replace function only seems to work on the currently open source file (i.e. 1 module, procedure or function). I don't think I can get it to replace all calls within the entire project even though there seems to be a 'global scope' option. It'll work, but take a while to open and perform the replace on each module.

4. I could perform a global replace of LogMessages() to something PAC friendly by editing the .ctd file directly - may work, as long as there is no authentiaction on the file, but not a great idea.

I think what PICED really needs is to allow LogMessage() for PAC projects, but stub it out when it is run on the PAC. Conditional compilation, or even just a global constant that told you what the current hardware target was, would be great too, cos then you could have a project that worked for both PAC and CTouch just by changing the target. This would allow better debugging as you could setup a 'test' screen with buttons and text windows, etc.

I'm sure you guys have your own ideas where PICED is going, with relation to these areas. Any ideas on how best I can currently get some reasonable debugging facility. I'm currenly planning to change the project type to CTouch for debug, then change back to PAC and perform a replace directly on the .ctd file of LogMessage() to WriteLn() when I am compiling for the PAC.

 

The logic gets executed around once per second. Refer to the "operation" topic of the logic help file. Before it runs the logic, the contents of the output window are cleared.

It should be OK to do this.

This is not curently supported, but is on the list of things to do (#7007).

Make it so that you pass it a single string. eg

Code:

procedure DebugMessage(s : string);
begin
  LogMessage(s);
end;

...

{ elsewhere in your code }

if not IsPAC then
  DebugMessage('Test');

Global search and replace is on the list of things to do (#7000).

This is a little risky.

This is on the to do list (#8226).

 

For anyone following this:

There's a small problem with changing the project back and forth between PAC & CTouch.

When you change the type, you have to save it as a new project. Even though you can overwrite the original file, it still sort of gets saved as a new project. Doing this partially resets the daylight savings 'schedule'.

I changed from PAC to CTouch and back to PAC. On the next transfer it gave me a warning saying I hadn't yet created a Daylight Savings schedule (which I had done previously). I followed the usual steps to create it, and when I vewed the schedules, I could see the original ones there as well as the new ones. The "action" on the original ones seemed to have been blanked out.

I'm sticking simply with WriteLn and pausing the project to view the output between loop iterations. Although it seems that when a delay() is active in a module I need to 'run once' LOTS of times to get to the next interesting bit after the delay.

Debugging on the PAC is a bit of a 'catch 22'. I have to have logic span multiple iterations of a module in order to avoid "too much logic", but this means I lose my debug flow as it is cleared on each module iteration.

Brad.

 

Have you tried Darrens previous suggestion ?

You can use the LogMessage function to write a message to the log file. See the Logic Help file, Debugging Programs section, Debugging Support Features topic.

 

Phil,

LogMessage is not currently supported on the PAC.

Brad.

 

A lateral thought ...

Hi folks ... I'v been thinking about this because of the problems I have had debugging my code.

What about creating a simple procedure to write asynchronasly to the RS232 port and catching the text in a terminal emulator.
You would need an extra serial port on the PC but it is probably worth the messing about. you could probably turn it off too by monitoring one of the ststus lines and skipping the code when no link is prescent. it would just be a matter of plugging in after that.

I also noted that some of the statements work diferently when they are run in symulatiuon mode and this aproach would provide debugging info for the transfered code running in its final state.

Thoughts?