Extension awaiting review

Another tip: in the forum’s edit window there is an entry pane to the left and a preview pane to the right. In the preview you can see the way that the forum’s formatter will present whatever you have typed.

That’s where it is on my UK Mac keyboard too, but @Camlaman is on Windows.

I’m not running Windows nor on a GB keyboard, but looking it up on Wikipedia, it seems like this is the key?

I am running windows and the key is as described by @McGordon it is under esc, next to 1 above tab.

thanks everyone, I’ll use the the key under the Esc key.
Hope it looks better for everyone now.

It is still not quite correct.
You really need to tell Discourse what language to lex for. In the case of error messages and backtraces, use …


… as the opening line of the code block.

Further up in your post was a line of Ruby code that needs to be blocked using the block opener …


For a complete explanation see this …

1 Like

thank you Dan and everyone. I marked the ruby code as ruby and the backtrace as text. Hope the message is more easily readable now.

Okay well … Line 4923 in doorplus …

    else UI.messagebox(languageHash["Sorry, FMS_WinDoor+ could not find a license so it will not run the extension."])

… looks as though the "else" should be on a line of it’s own, the messagebox call on the next line, and followed by a closing "end" statement.

The argument statement looking up the string in languageHash seems to be okay.
At first glance it looked like "FMS_WinDoor+" was a variable reference, but it is (I am supposing) the “official” brand name of your extension ?

That aside, … sometimes the line numbers reported by Ruby exceptions are off by a few lines because comment lines are not counted. So if there are comment lines above line 4923, look above or below where the error is reported to be. (Ie, sometimes it’s a “ballpark” number.)

The error message text is still not correct, and we still cannot see all of the error messages.
Ie, … the first message line is now completely swallowed.
The second one, the entire message and enclosing <> “pointy” brackets have been swallowed and it comes out like…
Error: #

It should come out like …
Error #<ExceptionClass: I'm a nifty error message telling you what went wrong>

The forum is also still swallowing the method names at the end of many of the backtrace lines.
"… doorplus.rbe:4923:in `’
"… doorplus.rbe:21:in `'
etc., …

thank you for your patience with me. I placed the back ticks and the word ruby on the same line as that which was swallowed. I’ve moved the back ticks and the word ruby to the line above the back trace and all seems well again.

These lines have a scroll bar on my machine. If I scroll over I can see the whole line.

The “else” followed by code on the same line is something I’ve been doing without thinking about it. Is that wrong? It works on my machine and has passed previous reviews. The construct does have a closing “end” statement on the next line which I did not quote.

I have removed the line with “else UI.messagebox etc…” and resubmitted the extension for review. I don’t think it ever got called. I guess if there is no license detected the script gets stopped in its tracks and SketchUp delivers the message about there being no license.

I was not aware of the possibility that the reported line numbers might be a few lines out. That is confusing.

I have simply quoted the reviewers email. There were no actual Errors reported. Just the word Error: # and then the code lines poured out thereafter.

That is why it is impossible for me to do anything to fix the problem.

Thank you again for taking so much trouble with this issue.

Ouch! That would say that the reviewer was careless when copying the error message to the email!

Yes it will parse and run okay, but is poor form.

It is more likely that the reported error line number is off by a few lines.

(This is one reason why I break up extensions into smaller files. You’ll not likely find me publishing a file with 5000 lines. That is just a maintenance nightmare.)

Yes, (as Christina said above) it is not good form to have modal messagebox pop up during the SketchUp startup cycle. This stops the startup cycle.

You should instead just open a non-modal WebDialog / HtmlDialog and display your “no license” message in that. This way it will not stop SketchUp’s load cycle.

Or,… for v2017+ you might leverage the new UI::Notification class.

This comes from the Ruby parser ignoring lines that are 100% comments.
If the Trimble EW review code relies upon the line number reported by Ruby exceptions, then the discrepancy is passed along.

Everywhere we’ve tried to say that the code block delimiters are lines unto themselves.
I gave you a link to a pinned wiki post that clearly explains this, and gives five examples.
(It amazes me how some people have the “Charlie Brown syndrome” where nothing ever seems to go right for them.)

This is not Ruby code. As I explained above and in the wiki post, …
you should use text as the language for blocks of error text.

however, you also said

If you are using Gmail’s web-based email client to read your email, then it will have the same special character “swallowing” issues that this Discourse forum does.

So what you probably did was copy the “abbreviated” error text from Gmail to start with (assuming that Trimble’s email client did not strip out the error messages on the way out of it’s client.)

To see the “unabbreviated” message from Trimble, you need to open the message in Gmail, then click the “More” (down arrow) button at the top right of the Gmail message frame. (Crop image below with orange box drawn on the “More” button.)
From the “More” menu choose the “Show original” menu item. The source of the message will be loaded into a new browser tab, and you can copy and paste from there.


I need to say that all these issues of yours should have been posted from the start in their own issue thread.
Basically you’ve hijacked jeando’s issue thread, which could have been marked as solved already.

Your issue has nothing to do with the excessive wait time that is the issue of the original thread’s starter, and is only slightly related because it is also loosely about extension review feedback.

The forum guidelines ask you not to “divert topics midstream”, which I will admit is somewhat vague. But this is what you did, diverting from their issue to yours. (Now how would this thread be marked solved?)

But we’ll use this as a learning opportunity so that hopefully from now on you’ll be better informed.

… but my “patience” has worn thin. Basically I’m spending my time explaining basic facts that anyone can find out by research or reading user guides to find out how things work, … ie, Gmail, email in general, Discourse hosted forums, etc., and paying closer attention to details.

thank you for you assistance and advice

For those of you who got the EW emails in your Spam folder, can you report back what Gmail says about why it got marked as spam? Gmail should show a line about this when you open emails in the Spam folder:

1 Like

Hi, here is what mine shows…


This was the exact same message I got!

From Google’s Bulk Senders Guidelines(emphasis by me)

Mail classifications depend heavily on reports from users. Gmail users can mark and unmark messages as spam, and can move non-spam messages between inbox tabs. In both cases Gmail learns from user corrections and over time automatically adjusts the classification to match users’ preferences.

So, y’all can help solve this (and teach Gmail) by marking the message as not spam.

But, there are also things Trimble can do to identify their messages as not spam (authentication, etc.)

1 Like

I marked them as not spam which before your post did’t know one could do. Thanks!

1 Like

Thanks for the insight to what Gmail is reporting. I’ve opened a case with the EW team for investigation.


Where does the Learn More link lead to?

Sorry but when I unmarked the email as spam it no longer shows the message with the link now. :frowning:

However, it might be the same link Dan Rathbun posted…