HatchPatternTable & Hatch.Explode Bug in RhinoWIP?

Hi there,
i found some issues with the HatchPatternTable in RhinoCommon in the latest release of RhinoWIP. In this post @dale describes, that the predefined Hatch Patterns are not in the table until used by the Hatch command.
When any change happens in the Document Settings they’re all appearing in the HPT. Programmatically this is not possible to achieve.
By using the Hatch command you can add one after the other. In Rhinocommon i could get around this, by calling the Hatch command secretly. I think this is not a clean solution and users will experience some strange Behavior, with this solution. Also if the file %appdata%\McNeel\Rhinoceros\5.0\Localization\<language>\Support\hatchpatterns.txt exists i need to add the patterns programmatically to the list. Can you provide some information (localization & filepath related) for a stable solution?
Before i start this workaround: Are you planning to get this to work like in Rhino5, where all predefined patterns were listed in the HPT on startup?

Another issue is clearly a bug: Exploded hatch results are always empty.

Thanks in advance,

HatchTableBug.gh (7.7 KB)

Hi @FlorianFrank,

In the Rhino WIP, there always a number of pre-canned hatch patterns you can access. For example:

var grid60 = Rhino.DocObjects.HatchPattern.Defaults.Grid60;;
var index = grid60.Index; 

Regarding Hatch.Explode, yes, this this is a bug that I have logged.


– Dale

Ah i knew there is some hint. This makes it very easy to provide a solution. Thanks a lot!

This is my workaround: Rhino5 & WIP safe code :wink:

Type defaults = typeof(HatchPattern).GetNestedType("Defaults");
MethodInfo findName = RhinoDocument.HatchPatterns.GetType().GetMethod("FindName");
if(defaults == null || findName == null)

PropertyInfo[] defaultHatchPatterns = defaults.GetProperties();
foreach(PropertyInfo def in defaultHatchPatterns)
  HatchPattern pattern = (HatchPattern) def.GetValue(null);
  if(findName.Invoke(RhinoDocument.HatchPatterns, new object[]{pattern.Name}) != null)
    Print(pattern.Name + " already there.");


@dale I’ve run across the bug you logged twice in the last couple of months Hatch.Explode fails on hatches not owned by a document Any news on a fix?

Can I vote to prioritize a fix? Do we need to send cake?

I can work around by making a document controlled hatch but it is a bit of fudge

Hi @david.birch.uk,

Please no - I’ve had my fill of Christmas treats.

I’ll have another look at this issue this week.


– Dale

RH-40690 is fixed in the latest Rhino 7 Service Release Candidate

1 Like

@dale @brian Thank you for looking at this, much appreciated.

I have downloaded the latest Release Candidate and I can confirm this fix works perfectly :smiley: