Did more searching, and found one spot that said the source couldn't be changed (at least not in the way I was meaning). I guess to do what I really want to do, I'd have to dive deep into this, and I just don't have the time since my development work is a "side" project at work.
I DO however have time to use TT's SKUI, so that's what I'm going with, since I have already used it for a couple dialogs already in this project.
Posts
-
RE: HTMLDialog - Change source on the fly? Possible?
-
HTMLDialog - Change source on the fly? Possible?
I'm just now digging into HTMLdialog usage, as my plugin has kind of outgrown the limited input boxes.
I tried building a test function, which would build my HTML into a string then assign as the source of the dialog. And it works, for the initial page build and show, but after the user picks something from a dropdown and clicks a button to apply the choice, I want the page to re-load with the selected item in the dropdown changing - but after the button is clicked, the dialog seems to re-load with the initial HTML code, or if I try to rebuild the string and reassign the source, I get a blank window.
Can the source of the dialog be re-assigned while the dialog is open?
I've tried to find good examples of how to do this, but all the examples I find seem to be so simple as to not address this, or so over my head they're not much help...Thanks!
Test code below, hope this makes sense... and not too ugly:
module Htmlexample def self.show_dialog model = Sketchup.active_model attrdict = model.attribute_dictionary('BCEWP') usage = 'BldgMod' html = '' html = ' <!DOCTYPE html> <html> <head> <title>Cutlass Dialog</title> <link rel="stylesheet" href="' + Sketchup.find_support_file('Plugins') + '/dialtest/layout.css" type="text/css" media="screen" charset="utf-8" /> </head> <script> function sendDataToSketchUp() { var user_module = document.getElementById("id1"); sketchup.getUserInput(user_module.value) } </script> <body> <div class="content"> <form> <select id="id1" name="modules">' $lastmod = MDAT(0, 'LastUsedBldgMod') attrdict.each { | key, value | if key.to_s.include? "Last" else if key.to_s.include? usage if value.to_s == $lastmod html = html + '<option value="' + value.to_s + '" selected>' + value.to_s + '</option>' else html = html + '<option value="' + value.to_s + '">' + value.to_s + '</option>' end end end } html = html + '</select> <button onclick="sendDataToSketchUp()">Confirm</button> </form> </div> </body> </html>' options = { dialog_title; 'Choose Module', preferences_key; 'cutlass.dynodial', scrollable; false, resizable; true, width; 300, height; 110, min_width; 250, min_height; 70, style; UI;;HtmlDialog;;STYLE_DIALOG } dialog = UI;;HtmlDialog.new(options) dialog.set_html(html) if dialog.visible? dialog.bring_to_front else dialog.add_action_callback("getUserInput"){|action_context, user_module| puts("JavaScript said user_module is #{user_module}.") $lastmod = user_module.to_s MDAT(1, 'LastUsedBldgMod', $lastmod) } dialog.show end #if end end #module
-
RE: Ruby Component Insertion and Attributes - Not Updating
Just now saw this - I have been unable to get a batch redraw of DC's to not take significant time. It seems the more DC's you redraw in the same operation, the longer each successive one takes to redraw.
Eventually, I found a way around this by simply scrapping my usage of DC's and switching to groups. Operations on groups are essentially instantaneous.
I'd use DC's if it's one or few objects at a time, or something I want the user to be able to interact with via the DC interface, but most of my plugin's objects are not that - I'm manipulating them with my code. Since I'm doing Engineered Wood Products layouts on very large multifamily buildings, I end up with thousands of objects to manipulate, and DC's simply didn't work well enough, as they were too slow. And the fact that even changing one property - even one that doesn't affect geometry - forces you to have to redraw them each, that time involved was a deal-breaker. -
RE: SVG Toolbar Icons - Gradients Missing
GIMP doesn't do vector graphics, no? It can import, but converts to raster. I tried a couple apps that work with SVG, to no avail - they all output different code in the SVG, and each one did different (incorrect) things when I tried to use them on my toolbar in SketchUp.
-
RE: SVG Toolbar Icons - Gradients Missing
For what it's worth, I think the problem with Inkscape is that it makes the gradient in two parts, and has the gradient units listed as "userSpaceOnUse", and I think SketchUp doesn't know what to do with that. SketchUp likes the X/Y portion to be formatted in percentages, not on-the-fly which the userSpaceOnUse implies.
-
RE: SVG Toolbar Icons - Gradients Missing
Yeah, not sure what else to try. I guess I either stick with images or manually edit the SVG code so SketchUp will read it properly, for each icon. Which I have no desire to do, as I have 59 buttons as of now, so... yeah.
-
RE: SVG Toolbar Icons - Gradients Missing
Confirmed - when I edited the SVG code to look like this:
<linearGradient x1="50%" y1="100%" x2="50%" y2="0%" id="linearGradient-1"> <stop stop-color="#ff00ff" offset="0%"></stop> <stop stop-color="#ffd2ff" offset="100%"></stop> </linearGradient>
then the gradient DID indeed show up.
So, anyone know of an app that will put the SVG code in a format SketchUp likes?
-
RE: SVG Toolbar Icons - Gradients Missing
Attached is the stock create camera SVG for comparison.
And yes, I tried using their SVG's and they work fine.
Added the smoove icon.
-
RE: SVG Toolbar Icons - Gradients Missing
I opened the advance camera tools and sandbox tools SVG's by opening in Inkscape, and I can't for the life of me spot anything special about the gradient fills in, for instance, the smoove tool icon, or the add camera icon. The only thing I obviously see (in Inkscape, anyway) is that the gradient names are negative numbers in the stock SVG's. Looking at the code of the SVG, there are substantial style differences between what Inkscape generated and what the stock files have - how to fix this, I don't know. I'm not an expert on the SVG file format.
-
RE: SVG Toolbar Icons - Gradients Missing
I'm in Windows, so I can only use SVG, no? My understanding is PDF is for OSX... am I wrong?
Anyway, I tried the file you sent, and it only showed the line-work. See the attached screenshot - it only showed the outline of the box.
-
RE: SVG Toolbar Icons - Gradients Missing
So, it loads fine in both Opera and Chrome and appears as expected with the gradient. I ran it through the link you posted, and it again appears fine in browsers.
In SketchUp, it made no difference. It drops the gradient out, only shows the line-work, and the fill appears to be transparent. -
SVG Toolbar Icons - Gradients Missing
I'm trying to convert my PNG toolbar icons for my plugin to SVG. I have looked at existing and fully working SVG icon files (such as the ones in the advanced camera tools, and others). For some reason, though, even when using one of those files as a template, SketchUp is not rendering gradient fills when it draws the icons. When I do a solid fill, it works, but when I switch to a gradient, it disappears. Does anyone know how to solve this?
If it matters, I am using Inkscape 0.92.2 to create the SVG files.
Gradients work fine for some of the stock SVG's, as a for instance, look at the "Smoove" icon file - it has 18 gradient fills and they all work fine on the toolbar.
-
RE: Layer Material Alpha - Not Possible in API?
I don't know - I may do something like that, but I probably won't. I have a new tool I made as part of my plugin and it creates a draw layer for different defined area types, and I just wanted it to have some level of transparency automatically so it didn't totally cover what may be underneath. But, I think I'll leave it alone for now. I just just figured I must have been missing something, as setting the layer appearance seems very... basic, to be a missing feature.
-
RE: Layer Material Alpha - Not Possible in API?
Yeah, from what I've read, under the hood the layer DOES have a true material, but the API only allows access to the color via the layer.color command for some reason - I tried setting the alpha on the layer.color and you're right, it only affects the color and not the true material, forcing you to have to use the mouse like a pleb in order to get transparency in Color By Layer mode. I really, really wish there was a true layer.material method... or even a hack via my own routine to do it, but apparently not.
-
Layer Material Alpha - Not Possible in API?
I've looked all over and can't find a way to accomplish this - is it not at all possible to set the alpha/transparency of a layer's material via the Ruby API?
-
DC/Group Scale Along Object Axis?
Question: Is there any easy way I'm missing to scale a DC or group along the instance's own axis?
When you perform a scale transform, I know you can choose the origin point, and the scale for each axis. BUT, when the instance has been rotated, know scaling along say the green axis will give you skewed results. Is there a way to easily scale along the INSTANCE's green axis and not the model's to prevent unwanted skewing/stretching?
The way I've been doing it, I rotate the object back in-line with one of the model's axis, scale along that axis, then rotate back... but this has always seemed silly to me.
Thanks!
-
RE: SU 2017 anything new in the Ruby API?
@driven said:
@unknownuser said:
...it groups them together, moves the group, then explodes the group...
exploding now deletes all references to the group entities, i.e. they all are 'deleted entities' after the explode...
in one of mine I 'now' store the face.bounds.center.z and then after exploding re-find faces using that as a conditional...
I believe the former ability to 'hold' the reference was a SU 'hack' and some of these are being 'put right'...
john
I discovered this in bug testing, can confirm. It kind of sucks, as it was nice to store a selection set in an object array, manipulate, then get your selection set back by selection.add(array) which you can't do now since it views the objects as 'deleted.'
Alternately - and this may work well for your case, as even edges/faces/etc get these - each object now has a property called persistent_id, and by referencing back to that you wouldn't have to compare geometry (if I read your post right). My work around for now is to store the persistent_id's in an array, then go the the drawing objects and find the ones that have those id's when I need to reselect them. This is way, WAY slower than just being able to reference back to an array of entities, but I guess it is what it is... unless someone else knows of an easier way to get the selection set back.
-
RE: SU 2017 anything new in the Ruby API?
There have definitely been changes, I just can't find a list of what they are - my in-house plugin I've been using and coding for almost 2 years got totally busted by 2017. I'm getting all kinds of errors, including in some simple code operations that I wouldn't have expected changes in... kind of bummed. Now I'm going to have to figure it all out and fix... dang.
Does anyone have a list anywhere of the API changes?As an example, one of my many tools is a shortcut to scoot objects around. It iterates through the selection, adding each entity to an array. Then, it groups them together, moves the group, then explodes the group. The grouping/ungrouping forces a deselection, so then I use selection.add(array) to re-select the original selection. SU 2017 errors on the code that works in 2016, telling me my array is the wrong argument type. I have tried to debug, testing that the array is indeed an array and contains objects, but then when selection.add(array) runs, it tells me it's the wrong argument type. Why? Works fine in 2016 and 2015.
-
RE: Dynamic Component Instances and File Size?
@pcmoor said:
Its all got to do with DCs, as observed moving them individually after a copy make SU update everyone to an unique instance. This issue has been raised with the powers that be, however it remains to see if any resolution in the next release
An alternative which seems to work is to group the copies. Quarantine. The group can be moved and another group of same components if altered inside does not effect similar groups.
Yeah... also not incredibly feasible, given the flexibility I need. I guess I'm just kind of stuck with how things work right now. When I have layouts with as much variance in them as the example I attached, it becomes very difficult to group any items together.