Push Pull direction?

[TIG]

OK simple typo - simple fix.
THIS version recalls the dialog on an invalid entry...
See how I split a 'draw_pulley' method off from the un-callable 'initialize' that I had inadvertently typed....
You should recognize much of your code/steps in the reworked version - I've just avoided the pitfalls of your while-loop, un-ended if's etc etc...

---

!!!.rb

[Dan Rathbun]

$exStrings.GetString("Specifikationer") will NOT work. All LanguageHandler keys are English. The values that are returned, are in the other language.

You can open the strings files Notepad++ to see what the English key are.

Or at the console:
$exStrings.GetStrings.each_pair{|k,v| puts( %[key: "#{k}" = "#{v}"] )}

You can only access $exStrings if the Examples extension is enabled by the user. You should not rely upon it.

[TIG]

@dan rathbun said:

$exStrings.GetString("Specifikationer") will NOT work. All LanguageHandler keys are English. The values that are returned, are in the other language.

You can open the strings files Notepad++ to see what the English key are.

Or at the console:
$exStrings.GetStrings.each_pair{|k,v| puts( %[key: "#{k}" = "#{v}"] )}

You can only access $exStrings if the Examples extension is enabled by the user. You should not rely upon it.
I've removed these from my test code as he doesn't need them, neither does he need to test for 'platform' either...
I think that he's trying to apply methods and ideas from several sources and thereby making a script that's much more convoluted that it needs to be...
At the moment it's actually a simple script to ask for some dimensions and create a 3d pulley wheel from them...

[ksor]

I'll study the code and compare it with my thinking of Class, Objects, properties ect.

But I beleave this is "the right! structure or ... ?

The next Object - let's a a drivebelt - should use this code as "template" (the structure) or ...?

[TIG]

I think you are being over analytical.
There are many things you can do with Ruby, but in your case checking 'platform', 'translating' strings and so on... are far more than you need to do yo complete what you are trying for.
Meanwhile there are a few things that you are not doing, which we'll skim over for now as 'sufficient is fit'... it works without them and they are 'nice-to-haves'...

[ksor]

Ha, ha, too analytical - you can't be when working with OOP, I beleave.

I'm just trying to get a nice structure from begining of my Ruby eara.

Dan

???? I don't know what you mean:
"$exStrings.GetString("Specifikationer") will NOT work. All LanguageHandler keys are English. The values that are returned, are in the other language."

It DID work fine, eventhough I can see TIG changed it - in fact it did work.

My test for Mac or PC was code I found and I thought that code for Mac WAS special so why not make a test - but OK it's obsolete.

Now I'll try to finish the pulley thing !

[TIG]

The 'getStings' coded parts won't 'work' because it won't find your Danish word to translate in the standard '.stings' file, which is in English !
Adding that code does no real harm, other than slowing things down slightly, because every time it checks for a translation it doesn't find it and uses the original string anyway...
The principal of a 'language translator' tool is that the strings in the script-file also exist in a 'look-up' file - typically a '.strings' file [or for purpose made translators like my deBabelizer.rb it a .lingvo files]; the English word is matched against the foreign word FR Cat<==>Chat or ES Cat<==>Gato etc. I don't think Danish is a Sketchup 'locale' though. However if you are using an EN-US locale with a script using my deBabelizer lingvos appropriately then taking the standard ...EN-US.lingvo and swapping the Cat<==>Cat for Cat<==>Kat etc etc would display menus,prompts,dialogs etc in Danish strings rather than English...
I suspect this is something not high on your agenda...

The issue of testing for PC/MAC only arises when you do something that is platform specific - most simple API code is cross-platform; however, you might one day move on to Tools which for example involve key-presses, and these key-codes can vary between PC and MAC so you need to use different code depending on the platform test results; there are also add-ons like Win32ole.so and Win32api.so that add links from Ruby into the Windows system and even other app's like Excel - these cannot be used on a MAC so again you need to trap for that possibility... BUT your relatively simple code needs no sure 'traps'...

[Dan Rathbun]

@ksor said:

Dan
???? I don't know what you mean:
"$exStrings.GetString("Specifikationer") will NOT work. All LanguageHandler keys are English. The values that are returned, are in the other language."

It DID work fine, eventhough I can see TIG changed it - in fact it did work.

What TIG said is true.

You don't need to worry about translating plugins just yet.

$exStrings.GetString("khbgjubgeg663buib")
returns >> "khbgjubgeg663buib"
... because the key "khbgjubgeg663buib" does not exist in the hash, and the LanguageHandler just echos the key (assuming it would be a valid English string.)

It is a fallback feature. (I suppose Google should have output a "Key not found" warning to the console.)

[ksor]

OK - I see it's for internationalization of the code - I misunderstood this in the first place.

[ksor]

@tig said:

OK simple typo - simple fix.
THIS version recalls the dialog on an invalid entry...
See how I split a 'draw_pulley' method off from the un-callable 'initialize' that I had inadvertently typed....
You should recognize much of your code/steps in the reworked version - I've just avoided the pitfalls of your while-loop, un-ended if's etc etc...

Now I'm a little over analytical again - I think your code here contains a bomb:

			def draw_pulley()
                # default MINIMUM values
                @diaP = MINDIAP if not @diaP or (@diaP < MINDIAP) 
                @diaA = MINDIAA if not @diaA or (@diaA < MINDIAA) 
                @krvD = MINKRVD if not @krvD or (@krvD < MINKRVD) 
                @krvB = MINKRVB if not @krvB or (@krvB < MINKRVB)
				return nil unless self.dialog()
				self.draw_beltProfile()
                self.set_beltProfileOnWheel()
                self.pull_pulley()
                self.pull_krave()
		    end
			
		    def dialog()
					prompts = ["Skivediameter (mm) ;",
                           "Akseldiameter (mm) ;",
                           "Kravediameter (mm) ;",
                           "Kravebredde   (mm) ;"]
                    values = [@diaP, @diaA, @krvD, @krvB]
                    results = inputbox(prompts, values, "Specifikationer")
                    return nil if not results
					diaP, diaA, krvD, krvB = results
					if (diaP < MINDIAP) || (diaA < MINDIAA) || (krvD < MINKRVD) || (krvB<MINKRVB)
                        UI.messagebox("Mindsteværdi er genindsat - de(n) SKAL overholdes !", MB_OK)
						self.draw_pulley()
						return nil
					else
					    @diaP, @diaA, @krvD, @krvB = results
						return true
                    end
            end    

The call to self.draw_pulley is a sort of recursive - just returning nil would be better and then this in the initializing method:

				until self.draw_pulley() != nil 
            end

Right ?

[TIG]

Sorry, I don't quite understand your point...

The tool initializes, it runs self.draw_pulley(), which runs self.dialog() and tests for the validity of its ' return'.
If the user cancels the dialog ' nil' is returned and it stops.
If the user enters valid inputs it returns ' true' and the remaining steps are executed to completion.
If the user enters invalid input it then re-runs self.draw_pulley() [], which in turn runs self.dialog() and tests for its validity in its ' return' etc etc in a loop until either the user cancels or enters valid input...
[ after it re-calls the method it immediately returns ' nil' to the previously executing version of the method, so that one goes no further]
Note how two sets of references are taken from the ' results', one to test their validity and if OK then another @ set to be used in the next methods and also remembered for the next time...
I left it this way because that's what you originally showed... personally I feel that a simple
UI.messagebox("Values outside limits !\nExiting.") return nil
would do, but at least this way the user does get chances to try again with a valid input in a new dialog - if they want to give up they can just cancel the dialog at any time...