[Plugin]BuildEdge PLAN 1.0

aarondietzen

BuildEdge PLAN is released!

BuildEdge PLAN is a plugin for SketchUp for Windows (Mac version coming soon).

BuildEdge PLAN simplifies the creation and editing of walls and pitched roofs for modeling structures.

Visit http://store.buildedge.com/ to purchase.

Thanks!
Aaron

micione

Hi,
I must point out a conflict with 2D Tools (from TIG):
The tool shown in the photo is blocked by Bug Splat.
This does not happen if BuildEdge is uninstalled.
You can solve with the new version?

TIG

I suspect that this tool's code must be messing with the native group.copy or similar [one or two rogue scripts are culprits in doing this ill-advisedly [e.g. current SketchyPhysics], but yours is a new report!].
In the standard API when a group is copied it ought to return a reference to the copy.
Messing with a base class/method in a way that 'falsely' returns ' nil' will break a legitimate script that uses this method and expects a proper returned value...
copy=group.copy

reference to new group
...
then later
copy.explode
array of objects - HOORAY!
...
BUT later
copy=group.copy
nil
copy.explode
ERROR because you can't explode 'nil' !!! BUMMER!
Please review your encrypted code accordingly...

aarondietzen

Thanks, TIG! I will pass this along to the developers.

Thanks!
Aaron

orhun

Hi, I am a developer at BuildEdge.

I investigated this problem. Here are my findings.

The simple act of adding a Sketchup::EntitiesObserver to the model seems to trigger a crash in 2DTools (at least in 2D Fillet, which is the only one I looked at). Please see the attached TriggerCrashIn2DTools.rb file. You can disable BuildEdge plugin and activate this plugin. You should still observe the crash.

I think this is a Sketchup bug, but that being said I also found a workaround for 2DTools so that it doesn't trigger this crash. I am attaching a patch for 2DfilletTool.rb. The trick is to delay the erasing of original group after the first model.commit_operation. See the attached patch for details (patch.diff.txt).

A plugin that will cause 2DTools to crash.

Patch for 2DfilletTool.rb for a Sketchup bug.

TIG

Other developers [like me] who do legitimate operations, like erase a group after copying it, should NOT have to 'nail on patches' to fix their tools because your ill-conceived observer breaks things...
There might be many tools affected by your one code-set.
I have tended to avoid group.copy more recently and use a more convoluted add_instance workaround on most of my updated tools, simply because some scripts like SketchyPhysics have messed with the group.copy base class/method... This tool is one of a few still using it
BUT why should others have to compromise a one-step undo into potentially two steps [although your code does suggest it bypasses the undo stack ??]
I fail to see how this is issue is happening...
If the 'entities observer' class is broken then avoid using it, report it and get it fixed - don't expect others to work around its short comings...

I will NOT be changing my tool any time soon - I shall simply recommend that users do not use your tool, if they wish that my tool operates as it ought; after all it is your tool that is breaking things...

Why can't you just fix your code and/or use an alternative observer?

There has been considerable discussion about how NOT to use an entities-observer...e.g.
http://forums.sketchucation.com/viewtopic.php?f=180&t=46853&hilit=entities+observers
http://forums.sketchucation.com/viewtopic.php?f=180&t=20676
http://forums.sketchucation.com/viewtopic.php?f=180&t=17970&p=181668&hilit=entitiesobserver#p181668

What is your observer doing ?
Why does it interact with a simple operation like copying a group and later erasing it ?

EDIT: Would making my one line only...
gp2=gp1.copy;gp1.erase!;gp2.explode
into...
gp1.copy;gp1.entities.parent.instances[-1].explode;gp1.entities.parent.entities.clear! work within the same start..commit block BUT with far less trouble ?
Incidentally - this 'trick' is needed to force the geometry to update and get the edges to be formed correctly...

aarondietzen

Hi TIG,

Sorry if anything I or Orhun said came back as suggestion that YOU did anything bad. Orhun was just posting the suggestion that it seems to be related to a SketchUp bug (the file he posted is an empty observer).

We will be pointing this issue out to SketchUp (or Trimble... I am never sure how to refer to the company, as opposed to the software nowadays), as you suggested. In the meantime, thank you for the references to proper observer use. We will take a look at those topics and, hopefully, optimize our code in the future!

Thanks!
Aaron

TIG

You might note that I have fixed the 2dTools Fillet and reissued it anyway.

My version DOESN'T use the fix that your guy suggested... this is simpler.
It still works without a splat when the ill-mannered EntitiesObserver is loaded/running...

gp1=ents.add_group(arcbits)
gp2=ents.add_instance(gp1.entities.parent, gp1.transformation)
gp2.explode
gp1.entities.clear!

The "clear!" used on the group's entities means it's auto-deleted when the commit_operation runs at the end anyway [because it's then 'empty', and empty definitions are always auto-deleted on a commit - incidentally this way is also useful for removing any one definition from the Component-Browser, as opposed to using 'defns.purge_unused' which removes all unused defns, including preexisting ones that the user might want to keep available for later!], so no additional convoluted start...commit code is needed later on to effect a splat-free tidy up.
I don't see how gp1.erase! will cause a splat and gp1.entities.clear! doesn't - so it could do with a SUp API fix... but we might not live that long...

The API itself warns against using an EntitiesObserver - recommending a ToolsObserver instead, BUT the act of just loading one that does nothing, which causes a splat in another tool that's doing nothing wrong, makes there use AT ALL a worrying thing - what else might it yet break, that is totally devoid of any connection with your tool at all - it is only users testing and zooming in on the 'culprit' that told us of this 'unconnected' connection !
https://developers.google.com/sketchup/docs/ourdoc/entitiesobserver

@unknownuser said:

This observer interface is implemented to react to Entities collection events. To implement this observer, create a Ruby class of this type, override the desired methods, and add an instance of the observer to the objects of interests.

WARNING: The methods of this observer fire in such a way that making changes to the model while inside of them is dangerous. If you experience sudden crashes, it could be because of this observer. A potential workaround is to use a ToolsObserver to watch what the user is doing instead.

thomthom

@unknownuser said:

We will be pointing this issue out to SketchUp (or Trimble... I am never sure how to refer to the company, as opposed to the software nowadays), as you suggested. In the meantime, thank you for the references to proper observer use. We will take a look at those topics and, hopefully, optimize our code in the future!

The recommendation of not modifying the model in observer events (or at least be very careful about it - only when you have full control of the process) comes from the SketchUp team.
They said that for Dynamic Component for instance that needs to react to user events they make use of the Tools observer as TIG mentions. This is because reacting to Entity change events can all to easily cause bugsplats and other unexpected behaviour. The key is, and it's very hard, to find a good time to do changes. Some times you need to just monitor and cache the data from the events and act on that at a later occasion.

Btw, if you've not seen it, I've tried to build a chart of observer issues: http://www.thomthom.net/software/sketchup/observers/ )

aarondietzen

Thanks, guys! We will be looking at all this and figure out the best course of action.

Thanks!
Aaron

aarondietzen

BuildEdge PLAN is now available for Windows or Mac!

TBA

Can´t activate on mac now!
Strange, because it was possible before . (BE Plan was running before - in activation state !)

There was a "apple OS X graphic hardware update" some days before.
Maybe that´s the reason ??!

I think you must deactivate my license --> then I can activate it again.

Try´d to reach you about your support and e-mail, but no response.

Hope you fix this soon!

Regards,
Thomas

TBA

Hi,

I really disappointed about your support for paid/regular customers !!!

Resetting and activating again is no a thing of days - it´s a thing of a few hours !!!

I don´t need the app at weekend!

Regards,
Thomas

aarondietzen

Hi Thomas,

Sorry to hear you were having installation issues. It looks like our Help Desk is in touch with you, though. In fact, it looks like Rick in our office has emailed you and is waiting to hear back.

Unfortunately, we are limited as to the hours that we can offer support, but most issues that come in through the website are adressed within an hour (or, if the issue comes in at night, or over the weekend, we try to respond right away the next business morning).

Anyhow, please let em know if you have any issues with our software once you are up and running!

Thanks!
Aaron