Run GetIssueState and paste RH-84819. Does it print True or False?
– Dale
Yeah that looks right.
I tested with the code on this page:
Are you doing something different?
– Dale
So any of the toolbars seem to react the same within Rhino 8. Once they are docked, they cannot be resized. Per the above item, I turned on another toolbar, the Arc toolbar and docked it vertically.
Once docked it can no longer be resized, just like the command prompt toolbar.
If I run our command to unparent they work correctly.
Interesting though the Tooltips are working, I didn’t know about the tooltip issue until I read that linked post about R8 COM Interface.
I’m going to look more closely at that sample, and try doing the exact calls they are doing, and see if that improves our issue.
If you’re doing something different, I need to know. I fixed the COM issue specifically.
– Dale
So we do not use COM to launch Rhino. We are using a Skin.dll registered to our Scheme. And we have a Startup.exe which finds and loads rhino (among other housekeeping steps.
We pass our scheme as a switch to Rhino. The scheme activates our skin logic, which then manually loads our plugin. Once the plugin is loaded we proceed to open our Main Window and reparent Rhino’s Window to ours.
That last step, is where things start to fall apart for us.
I reviewed the sample app in the other post, and they are using some slightly different pinvokes for moving and sizing the window. I am trying to see if using those calls will be a fix for us.
I see they are using MoveWindow while we were doing this…
RH-84819 is fixed in Rhino 8 Service Release 14
I’ve rewritten all of our logic, removing any “extra” things we were doing, and only did the same pInvokes that the other sample plugin project was doing, but it didn’t have any effect to our issue.
If we switch to using COM to launch Rhino, could we still use our Scheme/Skin?
@jstevenson - I need a sample of what you’re doing.
— Dale
I have a feeling it is the same issue that causes our inability to interact with some of the rhino windows for like a sweep 2 command.
I created a test sample project, and video on this post:
But if that won’t help, I will put together another solution tomorrow which demonstrates this specific issue. I believe these all have the same underlying cause (whatever that is in R8)…
Hi @jstevenson,
The sample was helpful, thanks.
The command line resizing fix will be in next week’s SR14 RC, as well as a fix for the Sweep2 dialog issue.
– Dale
1 Like
Amazing!! Thank you so much. We’ve been maintaining a list of “trouble” commands that we automatically unparent the window when they run, and reparent the window when the command completes, just to handle this issue for our Rhino 8 users.
These are the commands we’ve found that had an issue:
“QuadRemesh”, “Sweep2”, “Sweep1”, “Rebuild”, “RibbonOffset”, “ShrinkWrap”, “Text”, “NetworkSrf”, “Make2d”, “Loft”, “Patch”, “SubDSweep1”, “SubDSweep2”, “SubDLoft”, “Vectorize”, “Heightfield”, “MatchSrf”
Thanks again for your help, it will improve our Rhino 8 adoption.
Jason
Do you have a YouTrack item for this change?
Hi @jstevenson - the fix is under the same YouTrack ticket (above).
– Dale
1 Like
Thank you. I see that now, I just wanted to check because I got another build today, but it didn’t change the behavior. Fingers crossed your change is still forthcoming.
Have a great weekend! I really appreciate all of the help you have been giving!
Jason
Hey Jason,
I just deleted your post as having old URLs to in-house builds can be problematic in the case someone happens to randomly download and install it several months from now.
We try to release a new release candidate every Tuesday so hopefully there will be one available in the next few hours.
Sounds good. Sorry I just copies the link from within the app. Didn’t realize that was an issue.