• Login
sketchucation logo sketchucation
  • Login
πŸ€‘ SketchPlus 1.3 | 44 Tools for $15 until June 20th Buy Now

Procedure flag resets itself?

Scheduled Pinned Locked Moved Plugins
7 Posts 2 Posters 490 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    honoluludesktop
    last edited by 10 Sept 2010, 21:37

    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 0

    def 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
    
    1 Reply Last reply Reply Quote 0
    • T Offline
      TIG Moderator
      last edited by 10 Sept 2010, 22:06

      I haven't looked closely at your code... BUT try to start your 'defs' with a lowercase letter NOT a CAPITAL letter ?
      def blockXXX(...) NOT def **B**lockXXX(...)
      Capitals are reserved for class/module and global constants etc...

      TIG

      1 Reply Last reply Reply Quote 0
      • H Offline
        honoluludesktop
        last edited by 10 Sept 2010, 22:27

        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" πŸ™‚

        1 Reply Last reply Reply Quote 0
        • H Offline
          honoluludesktop
          last edited by 11 Sept 2010, 02:23

          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?

          1 Reply Last reply Reply Quote 0
          • T Offline
            TIG Moderator
            last edited by 11 Sept 2010, 11:24

            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 @variable is only used in that activated instance of that class/module or group of defs.
            There is a @@variable type that you can make when the class/module is first initialized.
            These @ types remain within there bounds - unlike $variable which pervades all tools and can be dangerous if the name is 'common' - using $x in you tool is fatal to any other tool foolish enough to use it too - $x_my_special_tool_XXX_variable is less likely to clash!

            TIG

            1 Reply Last reply Reply Quote 0
            • H Offline
              honoluludesktop
              last edited by 11 Sept 2010, 12:51

              TIG, thanks for the lesson.

              @tig said:

              .......using @x in you tool is fatal to any other tool foolish enough to use it too ........

              " @x"'s a typo, yes. Assuming you mean "..using $x in..". Anyway I rewrote the code with @variable for those that have to be available for different procedures.

              1 Reply Last reply Reply Quote 0
              • T Offline
                TIG Moderator
                last edited by 11 Sept 2010, 15:19

                @honoluludesktop said:

                TIG, thanks for the lesson.

                @tig said:

                .......using @x in you tool is fatal to any other tool foolish enough to use it too ........

                " @x"'s a typo, yes. Assuming you mean "..using $x in..". Anyway I rewrote the code with @variable for those that have to be available for different procedures.

                Typo fixed 😳 πŸ˜’
                [I an conditioned not to type $ in front of a variable name!!!] πŸ˜‰

                TIG

                1 Reply Last reply Reply Quote 0
                • 1 / 1
                1 / 1
                • First post
                  5/7
                  Last post
                Buy SketchPlus
                Buy SUbD
                Buy WrapR
                Buy eBook
                Buy Modelur
                Buy Vertex Tools
                Buy SketchCuisine
                Buy FormFonts

                Advertisement