Control-Text-Font

Please also add:
- ability to hide pane lines (HidePaneLines() in WL6)
- user-selectable font & size; currently, fonts are just too big

Fonts are not too big for me, this may be how your Windows is set up.

They are too big for me.
I don't want to tinker with Windows settings as that will impact *all* programs.
WL6 has an option to select Font, style & size - it would be beneficial to have it in WL7 also.

Could you attach a screenshot?

QUOTE:
Please also add:
- ability to hide pane lines

Well, you could make the pane lines Color.Transparent. I've just wondering if that's a good thing or a bad thing?

What I did was make the pane lines really thin with a very light gray color. That works best for me.

@superticker,
I have done that too but that applies to ALL strategies.
If one wants to hide pane lines only in selective strategies then HidePaneLines comes in useful.

@Eugene:



This is a screenshot of a WL6 strategy I currently trade. ALL of the plots and values are important (please don't question why).

I have not yet translated it to WL7. There's an interplay here between multiple items - pane size, pane position, hide pane lines and font size - but you can pretty well imagine how it might look if there's a lack of flexibility among those items.

SetTextDrawingOptions is here in Build 14:

CODE:
public void SetTextDrawingOptions(Color backgroundColor, Color borderColor, int borderWidth)

Using build 14.
Has it now become possible to write text within a specified pane (other than the Price pane) as well as choose a font for such text and also for the indicator plot? As far as I can tell the new SetTextDrawingFont option only works in the Price pane.

It does work in other panes, here is an example:

CODE:

using WealthLab.Backtest;
using WealthLab.Core;
using WealthLab.Indicators;
using System.Drawing;

namespace WealthScript1 
{
   public class MyStrategy : UserStrategyBase
   {
      //create indicators and other objects here, this is executed prior to the main trading loop
      public override void Initialize(BarHistory bars)
      {
         bbLower = new BBLower(bars.Close, 20, 2.00);
         bbUpper = new BBUpper(bars.Close, 20, 2.00);
         PlotIndicator(bbLower);
         PlotIndicator(bbUpper);
         rsi14 = RSI.Series(bars.Close, 14);
         PlotIndicator(rsi14);
         SetTextDrawingOptions(Color.FromArgb(255, 255, 220, 220), Color.DarkRed, 2);
         FontFamily ff = new FontFamily("Wingdings");
         Font f = new Font(ff, 12);
         SetTextDrawingFont(f);
      }

      //annotate bars when prices cross lower bollinger band
      public override void Execute(BarHistory bars, int idx)
      {
         if (bars.Close.CrossesUnder(bbLower, idx))
            DrawBarAnnotation("Look out!", idx, false, Color.Red, 12, true);
         if (rsi14.CrossesOver(40, idx))
            DrawText("UP!!", idx, 40, Color.DarkRed, 12, "RSI");
      }

      //declare private variables below
      BBLower bbLower;
      BBUpper bbUpper;
      RSI rsi14;
   }
}

I want to write some boilerplate text in an indicator pane.
For the Price pane one has DrawHeaderText.
Seems like DrawText won't work for this purpose as it requires an int idx & double value parameters.

True, can you create a new FeatureRequest for this new enhancement idea?

Done.

What is desired is a parameter to temporarily change the font setting for a DrawText annotation as shown in the WL6 screenshot.


And the WL6 code to do that looks like this:

CODE:
Font cornerFont = new Font("Arial", fontSize, FontStyle.Bold);
WSObj.AnnotateChart(messagePane, cornerMsg, WSObj.Bars.Count-11, yPosition, msgColor, Color.Empty, cornerFont);

But the current WL7 DrawText primitive is missing that font parameter.

CODE:
//Font cornerFont = new Font("Arial", fontSize, FontStyle.Bold);
usb.DrawText(cornerMsg, ts2frame.Count-11, yPosition, msgColor, fontSize, messagePane);

And once it's changed with SetTextDrawingFont(), there's no way to revert it back to the default (preferences) setting again. If I wanted to affect the default font, I would just use the preferences setting, not the SetTextDrawingFont() call. I would remove the SetTextDrawingFont() call, and tell users to use preferences for global/default font changes.

You can add a feature request for something like a ResetTextDrawingFont? Or you can call it again with I believe Arial 8.

How about a feature request to simply add a font parameter to DrawText() so SetTextDrawingFont() won't be necessary. That's a cleaner solution. Basically make it work like WL6 does it.

Flipping back-and-forth between fonts with SetFont.... ResetFont... is messy and error prone.

I would just implement it in the cleanest way possible without any feature request. Following clean program design shouldn't require vote approval.

The feature request is to help us prioritize what to work on.

QUOTE:
The feature request is to help us prioritize what to work on.

I totally agree you need to prioritize, and I also agree feature request voting is a excellent way to do it.

But the highest priority of all is to implement sound program design in all cases. In this context, that means minimizing the number of lines of code in the strategy by employing high level primitives. So adding another "optional" parameter to an existing primitive (say DrawText) is a no brainer.

In contrast, proposing an entirely new primitive (say ResetTextDrawingFont) is a messy solution. Of course, one wants to be able to revert to the default font, but the best way to do that is to never deviate from the default font in the first place.

My concern is with the code implementation part (the existence of SetTextDrawingFont), not the feature voting process. I would roll back the SetTextDrawingFont implementation in favor to adding a font parameter to DrawText() as WL6 would have it.

I think WL has done an excellent job in using polymorphism in its primitive (framework) design. But creating SetTextDrawingFont() is the exception. Maybe I have just taken too many software engineering classes. :-)

That makes sense, but i would still like to see that in a non-closed feature request just so the idea doesn’t get lost in the shuffle.