NX8.5 Bug in Userinterface 1

[icetea73]

It seems that NX has a bug in regarding the enabling/disabling of available commands.
Buttons whose commands are unavailable are normally just grayed out but there are some buttons that are removed and then re-added.
The problem with this, is that it scrambles the arangement of floating toolbars. This is really annoying when used to work with floating toolbars.

Please see the little video in the attachment as a demonstration of what I mean. The effect does not happen only on the shown toolbars.

I'm just a student, so I can't report the bug myself... still would be glad if this could be fixed in future releases.
Is there anything I can do myself about this? Changes to the tbr files or anything?

 

[JohnRBaker]

I suspect that this will soon be a non-issue.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.

 

[Toost]

The shown behavior does not repeat on my computer.
I tried to place vertical , undocked ( i.e floating) toolbars outside the NX window. Their icons become grey when the sketch is edited, no blink/ no hide-show etc.
The Edit Feature toolbar does change which icons are displayed but it returns to it's previous mode as soon as the sketch is finished.

- Must you have these toolbars floating ?
- Why not make the NX window larger and dock the toolbars onto the edges ?
Are you running a certified computer ? ( or at least a computer with a certified graphics card ?)

Regards,
Tomas

 

[Toost]

Reading Johns comment, i get worried. Really worried.

- I indeed hate the Windows ribbon bar uif, i have been using the ribbon bar in the Microsoft products for over a year and i still spend too much time searching for the simplest things. Where are for example the Help - about ? File - Properties ? The ability to organize the toolbars the way you would like ?
The future isn't that bright.

Regards,
Tomas

 

[icetea73]

@ John:
So what does your comment actually mean? Will not get fixed and ribbon bars in the future?

@ Thomas:
The behaviour is reproducible and not hardware related. Nx (V8.5.1.3 Mp1, X64, Win7) resizes the toolbar windows intentionally. It is not a glitch.
The small window was just to shoot the video. The machine has three 24" screens. Left screen for the navigators, center for the main window with no docked toolbars, right screen with floating toolbars.

 

[JohnRBaker]

No, there will probably be nothing done to change the behavior of toolbars which you're seeing, particularly with respect to your example since entering the Sketch task is almost as if you had switched modules. What would you expect to happen to your Modeling toolbars if you were to switch to say Drafting or Manufacturing?

As for my 'comment', I wouldn't lose any sleep over what you might think it means ;-)

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.

 

[icetea73]

Everything is good when entering the sketch task environment ("Edit with Rollback" in my example)! It has it's own profile and behaves in a predictable manner as every other nx application.
The shown behaviour only happens if the edited sketch has dependent features so that certain commands would become unavailable. But instead of graying out all unavailable commands, some are grayed out (which is great!) and other are silently removed and re-added when available again, messing up the whole toolbar arrangement.

 

[Toost]

When NX and I-deas was merged several years ago, there was extensive studies performed to ensure minimum amount of mouse travel and to reduce the number of button clicks etc. I hope that this is't ruined now... An extra click just to open the surface tab etc isn't that welcome.
-If it ain't broke, don't fix it.

Regards,
Tomas

 

[JohnRBaker]

That's part of the problem, when editing a 'Direct' Sketch, a significant number of other Modeling operations are no longer valid so if you had their toolbars displayed we had to do something to prevent you from tryng to use them and since the 'Direct' Sketch does NOT have it's own 'profile', unlike the traditional 'Sketch Task' does, which can control ALL aspects of what is displayed or not, the software has to resort to whatever tools it does have, which generally is limited to either graying-out an icon or in some cases, making them invisible.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.

 

[icetea73]

Well, ok. You don't seem to consider it as a bug.
Still I think that an "automatic scrambling" of the arrangement of the toolbars in the process of making certain commands unavailable/available is not what the user would expect and it is certainly evitable by just graying out all corresponding commands instead of removing some of them. At least if the application insists in removing command icons it should restore the original arrangement of the windows afterwards.

Thank you for the fast answers anyway. I really appreciate it.

 

[JohnRBaker]

While it may technically be a 'bug', since it only effects 'floating' toolbars it will, in all likelihood, only impact a very small number of our users and therefore would probably never get set to a high enough priority for it to be addressed. After all, this does NOT corrupt your data and while it's true that it might reduce your efficiency, it in no way prevents you from using the software, two criteria which are given significant weight when prioritizing any PR.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.

 

[icetea73]

Sure it has low priority and is a non-issue for most people. I agree. The discussion drifted away somehow.

My actual reason for posting was to ask if there is known way around it.
I was hoping that editing the affected tbr files could somehow suppress the dynamic removal/addition of commands and force that things are only grayed out instead...

I have written a dll that nx loads on startup that implements some features like snapping of floating toolbars against each other, anchoring them to screen edges, moving sets of snapped toolbars together, scrolling through sets that are bigger than the screen with the mouse wheel etc. Of course the dynamic resizing messes up the sets of snapped toolbars. In the process of developing these enhancements I had to hook into some functions of libugui.dll to add instrumentation code and find out other undocumented stuff.
So I already have my hands dirty - if I knew the functions names for adding/removing and disabling/enabling toolbar items I would figure out a way to get around the problem ;-)

ANY hint could help.

 

[kukelyk]

It seems there will be bigger problems with NX9 interface..


----
kukelyk

 

[Xwheelguy]

PLEASE don't go that route - I despise what MS did to their products. I also recall the studies Toost mentions being a real "selling" point for making those changes back then - now there's a hint of going backwards and requiring MORE clicks? C'mon man...

Tim Flater
NX Designer
NX 7.5.4.4 MP8
WinXP Pro x64 SP2
Intel Xeon 2.53 GHz 6GB RAM
NVIDIA Quadro 4000 2GB

 

[JohnRBaker]

As I stated before, there's absolutely NO reason why ANYONE should be losing any sleep over my comment. It's what you and others are saying that's causing the concern, and since it's based on pure speculation at this point, it means less than nothing.

John R. Baker, P.E.
Product 'Evangelist'
Product Engineering Software
Siemens PLM Software Inc.
Industry Sector
Cypress, CA
Siemens PLM:
UG/NX Museum:

To an Engineer, the glass is twice as big as it needs to be.