Procedure flag resets itself?
-
What am I doing wrong. I am calling a procedure "Entities_In" from another, "Block_In", but when it returns, "polyline_flag" is reset from "1" to "0". The "puts" are in the code for debugging. I verified that at the end of "Entities_In" that the flag is correct, but when it returns to where it is called from, within "Block_In", it is no longer set correctly. Is there something about passing parameters that I do not understand?
The "puts" as in the ruby console:
goto entin from blkin, plflag 0 polyline face PL_DFace_In POLYLINE return from plin, plflag 1 prior exit entin, plflag 1 return from entin, plflag 0def Block_In(count,dface_flag,dface_option,line_off,arc_flag,circle_flag,polyline_flag,insert_flag,block_flag,line,insert_off) if line == "INSERT\n" Insert_In(count,insert_flag,insert_off,line) else if line == "ENDBLK\n" block_flag = 0 else puts "goto entin from blkin, plflag "+polyline_flag.to_s Entities_In(count,dface_flag,dface_option,line_off,arc_flag,circle_flag,polyline_flag,insert_flag,block_flag,line) puts "return from entin, plflag "+polyline_flag.to_s end end end def Entities_In(count,dface_flag,dface_option,line_off,arc_flag,circle_flag,polyline_flag,insert_flag,block_flag,line) . . . if line_flag == 1 Line_In(count,line_flag,line_off,line) else if polyline_flag == 1 and dface_option == 0 Polyline_In(polyline_flag,line) else if polyline_flag == 1 and dface_option == 1 PL_DFace_In(polyline_flag,line) puts "return from plin, plflag "+polyline_flag.to_s else if circle_flag == 1 Circle_In(count,circle_flag,line) else if arc_flag == 1 Arc_In(count,arc_flag,line) else if dface_flag == 1 DFace_In(count,polyline_flag,line) end end end end end end puts "end of plin, plflag "+polyline_flag.to_s end -
I haven't looked closely at your code... BUT try to start your 'defs' with a lowercase letter NOT a CAPITAL letter ?
def blockXXX(...)NOTdef **B**lockXXX(...)
Capitals are reserved for class/module and global constants etc... -
Tried it, but "no can do". No caps, too bad, I used caps to make the code easier to read.
My problem reminds me of a "grade school" rule. "Pass on, no pass back"

-
OK, I figured out how to use instance variables by @variable. If I use them, will other plugins be affected in the manner of global variables?
I understand why not to use global variables, can the other types be problematic?
-
First the def's "no-CAPS" rule only applies to the first letter! So
def blockXXX2(a,b,c)is fine...
Conversely a class should start with a CAP [class BlockXXX]...
The@variableis only used in that activated instance of that class/module or group of defs.
There is a@@variabletype that you can make when the class/module is first initialized.
These @ types remain within there bounds - unlike$variablewhich pervades all tools and can be dangerous if the name is 'common' - using$xin you tool is fatal to any other tool foolish enough to use it too -$x_my_special_tool_XXX_variableis less likely to clash! -
TIG, thanks for the lesson.
@tig said:
.......using
@xin you tool is fatal to any other tool foolish enough to use it too ........"
@x"'s a typo, yes. Assuming you mean "..using$xin..". Anyway I rewrote the code with@variablefor those that have to be available for different procedures. -
@honoluludesktop said:
TIG, thanks for the lesson.
@tig said:
.......using
@xin you tool is fatal to any other tool foolish enough to use it too ........"
@x"'s a typo, yes. Assuming you mean "..using$xin..". Anyway I rewrote the code with@variablefor those that have to be available for different procedures.Typo fixed

[I an conditioned not to type $ in front of a variable name!!!]
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better π
Register LoginAdvertisement