WriteMessage leaves its message in the way

[JamesMaeding]

I know people have said to do this:

ed.WriteMessage(Environment.NewLine + "some message" + Environment.NewLine);

but that causes blank lines between if I am doing several writemessage calls.

It just seems broke. How come the editor leaves the message sitting there in the way?

How would I work around that in a non-ridiculous blank line adding way?

[Keith.Brown]

You have a newline at the beginning and the end of your message.  That is what is causing the double spacing.  Just add it to the beginning of your message.

Better yet, add an extension method to the editor that will always add a new line to the beginning of your message and you will not have to worry about it again.

[JamesMaeding]

Hi Keith,

I have tried both, with \n at end and without.

The code I showed (rhyme unintended) is what people always suggest, and it works for single statements thrown to command line.

If you use it with multiple, it does a blank line.

Your suggestion of \n only at beginning is exactly what I do now, and it does not behave nicely.

What happens is the message sits in the way of the next command.

Giving command line focus and so on does not help, only a \n at end helps, but screws up the multiple message situation.

I do have a function that adds the \n for me, my code was just simplified but exactly the syntax and parts involved.

I have tried it all ways I could think of, using "\n" and environ.newline...nothing behaves like good old princ in lisp.

thanks

[fieldguy]

A workaround is to reference System.Windows.Forms, add a Using System.Windows.Forms statement, and use MessageBox.

[JamesMaeding]

@fieldguy

Please understand that a box you must hit enter to, to continue, is unsuitable for general feedback to the user.

We affectionately call those "nag boxes".

You are correct though, they are an option.

thx

[ActivistInvestor]

---

@Anonymous wrote:

...nothing behaves like good old princ in lisp.

---

Sorry, I don't follow.  Editor.WriteMessage is essentially the same as (princ), with neither of them adding newlines before or after the string they display. They both call acutPrintf() under the hood, and are functionally identical.

[JamesMaeding]

I will do some tests to replicate this.

I did notice if I just do simple test command it does behave without \n at end.

That gives me some hope.

Many of my items involve dialogs or palettes so I need to narrow down when this is happening.

thx

[Keith.Brown]

Sometimes when I need to display a message to the user where I want to use more formatting than just a simple text message I use a desktop alert.  It does not require interaction from the user and can disappear after a specific amount of time if you wish.

Specifically I use this one:  http://www.telerik.com/products/winforms/desktopalert.aspx.  Their controls are not cheap but they are well worth it for me.

There might be free alternatives out there.

[JamesMaeding]

ah, very nice.

Get this, I did a lisp that uses grdraw to do "non-blocking" messages. I digitized the romansx character vectors so the font is scalable and so on.

I use it on startup to tell the user if app id count is more than 4000.

So these notifications are important and I will look at those controls indeed.