Thank you TIG! Much appreciated, was a bit stuck.

I think I understand better now what you meant before. Before when you said "code into a sub-def method", I thought you meant ADDING a method or "doubbling" the code. There's where I was lost, should have asked earlier for help but pride got in the way.

Very clever solution! And probably quite natural solution for some off you guys in here

I will digest this and continue. Thanks again.

Hi. I trying to figure out the "clever" way to setup the structure of the code. If anyone has any comments, I would be most greatful. Having decision anxiety.

I am little afraid to destroy the structure of current code and getting flamed for doing something inappropriate.
I'm trying to avoid using @varibles everywhere. I get the impression that could give some troubles later on.
The simplest way would of course be to repeat the whole last part(linecreation, intersection) without nesting so many methods, but that would probably be cheating. However the script is not that long so I guess it would not be a catastrophy to repeat things.
Also having trouble grouping. Where as we will have the structure:
(maingroup)/(hatchgroup1) (hatchgroup2)

Questions are. Should "face-cloning" be a separate method?
Should one create a method for only using 1 inputbox getting values twice?(2 promts, 1 box) OVERKILL?
Another possiblities is to recreate the linehatching and intersection in a submethod calling on @gents?

Hi Ken. Thoose layers thing are very good ideas! They may or may not be hard to do, not sure yet. But IF they get implemented one could have them as an option? I don't think it should be default behavior of the plugin.

@unknownuser said:

thanks for the running tutorial in making a plugin. This continued conversation is helpful

I thought I was babbling nonsense But if you like it, I will continue to report and discuss openly.

Kyyu. Many thanks again for your advice I think I am at sleep when you guys are active here on the forum.
Different timezones.

I will head for doing as you advice. Using @varibles just when needed. I tried the opposit, but it got messy, and inefficient. Your code looks well structured.

When ordering methods and things right now, I must also think a little bit forward about the next steps.
Added features like other hatch-types, and bugtracking etc. The "face-creating" part must be a method or a block itself(sort of main code), if I am going to use it with other hatch-types. The subroutine for crosshatches might get a little repetitive code, not sure yet. IF I will be able to do other hatch-types, it might be a good idea to split up thoose, AND the line-hatches in different modules. Calling from the main "face-creating" script. Eventually I might do a fast version
of crosshatching so you have something to try.

They say Ruby is an easy language to learn. I haven't got any experience of other languages, so I can't tell.
However there seams to be many ways to do things in Ruby, and that can get confusing for a newbie.

Jim. I like your graphic. Visual guides like that is very helpful.

Or do the arguments in the definition heading like TIG said
def hatch(angle,spacing,gents)

Hehum.. I'm to new to this.

Hmm I got the second inputbox poping up after line creating. It's quite instant response. So having the 2nd inputbox first
or after 1st hatching doesent really matter, "workflow-wise" that is. I wonder if it's a risky way of doing things.

Also wondering if I call on for 2nd Hatching, Using the line_making and intersect_method varibles in those are set
from earlier = @spacing and @angle. Could one use something like @spacing=20.to_l if not @spacing instead and just call the again in the method for crosshatching. Or would that mess up the default values, next time one run the plugin?

Could of course put the whole rest in the crosshatch method, bit doesent feel very clever..

Thoose are exellent ideas! See if I can get this crosshatching work first
Getting some hard time putting structure to the code.

I have made "line hatches" and "intersection" into 2 different methods. A heck of lot of instance variables..
I was wondering if it would be easier to let the 1st hatches get done first. Then make the second inputbox pop up?
Then just call the methods on @gents and do some sort of grouping. This can probably be done in several ways.
Question is wich method gives best performance, regarding workflow, edge creation etc.

Sergey. Yes that is the behavior of profiles. I can see the problem you are getting at.
If I put in an option for "keeping face", you will get that behavior WITHOUT manipulating the original selection. Hatched lines and faces in one separate group called "Hatching".
On top of that,(as TIG recommended), when you want crosshatching. There will be 2 groups in that "Hatching" group.

@unknownuser said:

Is that duplicate line needed at line# 136 ?

No

Thank you for spotting that Sometimes I get wierd results when I copy from ruby code editor and paste to Notepad ++.
Did not doublecheck the results well enough.
Note. It is AS ruby code editor, not Jims version. Is Jims more stable? I think it's a webdialogthingy-bug.

Thank you for keeping on testing stuff! It's of big help. How about a choice of keeping faces? With possibility to attach
material? That way one could use transparent material or whatever? Wonder if it is possible to use a dropdownlist getting the materials already added in the palette...

Anyway, must get this second crosshatching inputbox working correctly first, and do some fancy methoding.

OK. thanks. I have missed the notes part.

@unknownuser said:

some users don't/can't put their stuff in the main Plugins folder

Did not think of that good point.

@unknownuser said:

Also how about adding a Plugins [or Tools?] menu item so users can shortcut to it easily

Yes, yes. That should have been done earlier.

@unknownuser said:

'Yes' [default='No'] as second dialog opens

That's smart. I wasn't planning on doing it like that. But of course your way is more logical.
The code will need some work for this to happened. And I will try your method, if I can understand how to.

Thank you TIG I will work on you advice.
PS: If it looks like I make promises for new features to be added and expect TIG to come to the rescue, it's not like that.
I understand you have other business to attend to, and I'm greatful for all the help I get.
Thanks

Ok I see what you mean. I will take a look at that later on. My 1st thought is that it will not be that easy to do.
In native Sketchup just use offset, doing that in code is not that straightforward, from what I know.
Crosshatching is on the next TODO list, and TIG's recommendations for filepaths.
Could spend some time on those...

It is not the final version There are things to fix. But I'm happy if the plugin is working for you, keep testing.

@unknownuser said:

But I want to go further in my desires
How about this?

That can easy be made manualy in Sketchup if you use r.click intersect with selected(face and hatchgroup) so the hatched lines adds to the face. Then go into styles-> edit->profiles, and work with the setting there.

If you want border "thin" faces to be drawn, that's a different issue. This feature in code might not be that easy. I can have a look on that later. First I will try to get the crosshatching working.

One have to consider what feature to add or not. If that feature is 1 click in Sketchup, it might not be worth adding it to the code.

Very interesting experiment and find. I wonder how missleading sometimes the API really is?
And what reference should beginners use if not the API?

Kyyu! Thank you so much for your detailed explanation. Now I understand better. Much apreciated.
I think your intersect method is worth experimenting with for upcoming features. And or what features is possible.

@unknownuser said:

this plugin will be not freeware

No one in here needs to worry this will become a comersial plugin.

Yes, of course I need to make money. But I have gotten so much help from TIG and Kyyu, Jim and others, so going comers. would be HIGHLY unethical! If even legal? This is a great learning experience for me, and I will try too remain humble and listen to
advice and suggestions being made.

@unknownuser said:

in the new version of SketchUp this plugin should become a standard feature

Hatches, yes. So this work might be for nothing Although, it is possible only Layout will be the program that get hatches.

Ver 1.3 added!

Hole "issue" should work. At least it does for me..

Note. Crosshatching does NOT work yet. Only menu items has been added. Layer Hatching now gets made with hatching in it.

What say you about choice of keeping Face and being able to add material?

This version needs to be tested. Have not recieved feedback from TIG about this update, and that makes me nervous

Testing.

YES!!!! Faces with holes are hatching now. Will update tomorrow, hopefully.

Stupid newbie-mistake. I did not create "@face" object. So for ex bb=face.bounds
did not have anything to refer to since face was in Faces2go's scope. At least that is what I think happend.

Will test more before I celebrate too much...

Sorry TIG, I missed your post from yesterday. I wasent using return nil. I used =begin and =end. That works equally good?

Sergey, thanks for your suggestions I will probably go for something like the picture, first time around.
Unless I'm wrong you have to use webdialog for checkboxes, and I'll put that on hold for now.
More important issues to deal with first.

Hi Kyyu. Many thanks for your input and experimenting. Really appreciate it
I got a strong impression from reading this forum, that making groupes from selection is a bad choice?
Thats why I neglected my original idea and went for TIG's "face.clone iterating stuff". Don't you get splats doing it like that? Have you tried this inside a group? I got constant splats doing almost exactly as you did.

However grouping the edges before doing an intersect_with might be a good idea. That might actually be an easier method than iteration the edges for erasing? Depends on how "splat-prone" the method is.

About separating to 3 groups. Don't know if that is necessary? Doesent it suffice to add the hatches to a new layer? (Which is already implemented in my current code). This grouping In my opinion does no good for the workflow. Need more feedback about that, please

@unknownuser said:

Seperate out the code that draws the line pattern, into it's own method

Yeah, I know code's a bit messy, but doing a second hatching that is probably a must anyway.
I'm using AS ruby code editor. It's the same as Jim's no?

Thank you Jim and Kaas! And TIG's been helping me a LOT, that goes without saying.

This code gives me a face with holes. If I stop after this code.
But cannot Hatch faces with holes in full script.
Get an error
Normal (square faces) works fine in full script with the changed code, strange enough.

gp.layer=hatch_layer    # group to Hatching layer
      gp.name=name
      gents=gp.entities
      faces2go=[]
      face.loops.each{|loop|gents.add_face(loop.vertices)}
      
      gents.each{|face| 
      next if face.class!=Sketchup;;Face     
      face.edges.each{|e|
      if not e.faces[1]
      break
      end
      faces2go << face
  }
}
 
 gents.erase_entities(faces2go)                #erase the faces in the holes 

Not noow Kato!!

I don't understand Sergey. Do you want line weight? That is only possible
through styles in Sketchup. But it's a global feature. I am afraid I can't do anything about that. Maybe if thin rectangles are grouped with materials
like TIG,s dashed lines. But that is further on in developement.

Look at my last minitut for an example how you can use differnt styles, with edge profiles for ex.

Thanks for input Sergey! MUST CODE ON!!

And yes TIG. I'm trying!