smartview closing after goto window closed in GP
Fred asked 9 years ago
Is there anyway to prevent smartview from closing after closing a GP window? Happens everytime when I use the goto from the smartview window.
Answers
Patrick Roth Staff answered 7 years ago
Fred/Charlie,
While it is a pain point for the end user, I don’t believe it is cause by nor can be resolved by SmartView.
1. Why would we do this?
So the first thing I can think of is – why would we code this as a SmartView feature? What user would possibly want this to happen?
2. How can we do this?
From an integration standpoint, I’m not sure offhand HOW we would make the Navigation Pane come to the front as I can’t think of a way in a .NET VSTools assembly (which is what the internal version runs as) to actually reference the navigation shell and pull it forward.
3. How would we know when to do this?
A GoTo as called by SmartView can do anything and open ANY window. So from a programming perspective even if we wanted do something like this – not sure how we would (either to bring SV on top or to put the Navigation Pane on top). The reason is that we wouldn’t know when that GoTo window closed.
Yes I could do it if I knew which window would open in a goto – but there isn’t anything in SV that would know and keep track of that on a general basis.
To be honest, I’m pretty sure it is a Dexterity runtime issue that happened when GP first went MDI (from SDI when it was all in the same space). And the “root” issue is that even though it in the same exe instance as GP (since running as a vstools app), the .NET window isn’t treated quite the same as the Dexterity based windows. A second citizen class if you will.
I seem to recall running into this soon after the vstools/sdi was released but it wasn’t ever fixed by GP/Dexterity development.
You can see this happen a little differently if you:
open the GP and let the Nav panel open
open smartview
open a couple of GP windows (I chose customer maint and item maint)
now “stack” the windows in order of:
Nav Pane
SmartView
Item Maint
Cust Maint
Now click on SmartView (which comes to the top of course) and open a list and open a goto that opens a new window (like vendor maintenance).
Lastly, close the goto window (vendor maint in this example).
What I see is that my Customer Maintenance window is now on top and the SmartView is right behind it.
What it seems to me is that Dexterity activates the last Dexterity based window in the activation stack and ignores the .NET window (the SV window).
So, in my thought, this is an issue that would have to be resolved by Microsoft Dexterity Development. And since it has existed since inception – doesn’t look like that will happen.
What can eOne do about this to work around the issue and keep SV on top?
Well according to #3 How can we know when to put SV on top? – I don’t see how we could. Because again we don’t know what “goto” window that we have to watch.
So while a pain point for the customers, I don’t see a solution from eOne to solve it and would have to come from Microsoft.
While it is a pain point for the end user, I don’t believe it is cause by nor can be resolved by SmartView.
1. Why would we do this?
So the first thing I can think of is – why would we code this as a SmartView feature? What user would possibly want this to happen?
2. How can we do this?
From an integration standpoint, I’m not sure offhand HOW we would make the Navigation Pane come to the front as I can’t think of a way in a .NET VSTools assembly (which is what the internal version runs as) to actually reference the navigation shell and pull it forward.
3. How would we know when to do this?
A GoTo as called by SmartView can do anything and open ANY window. So from a programming perspective even if we wanted do something like this – not sure how we would (either to bring SV on top or to put the Navigation Pane on top). The reason is that we wouldn’t know when that GoTo window closed.
Yes I could do it if I knew which window would open in a goto – but there isn’t anything in SV that would know and keep track of that on a general basis.
To be honest, I’m pretty sure it is a Dexterity runtime issue that happened when GP first went MDI (from SDI when it was all in the same space). And the “root” issue is that even though it in the same exe instance as GP (since running as a vstools app), the .NET window isn’t treated quite the same as the Dexterity based windows. A second citizen class if you will.
I seem to recall running into this soon after the vstools/sdi was released but it wasn’t ever fixed by GP/Dexterity development.
You can see this happen a little differently if you:
open the GP and let the Nav panel open
open smartview
open a couple of GP windows (I chose customer maint and item maint)
now “stack” the windows in order of:
Nav Pane
SmartView
Item Maint
Cust Maint
Now click on SmartView (which comes to the top of course) and open a list and open a goto that opens a new window (like vendor maintenance).
Lastly, close the goto window (vendor maint in this example).
What I see is that my Customer Maintenance window is now on top and the SmartView is right behind it.
What it seems to me is that Dexterity activates the last Dexterity based window in the activation stack and ignores the .NET window (the SV window).
So, in my thought, this is an issue that would have to be resolved by Microsoft Dexterity Development. And since it has existed since inception – doesn’t look like that will happen.
What can eOne do about this to work around the issue and keep SV on top?
Well according to #3 How can we know when to put SV on top? – I don’t see how we could. Because again we don’t know what “goto” window that we have to watch.
So while a pain point for the customers, I don’t see a solution from eOne to solve it and would have to come from Microsoft.
When closing the GP window that the goto opened the main GP window is becoming the active window which makes it look like it's being closed. If you have multiple displays you could move SmartView to a different display.
I will submit a feature request to have SmartView remain as the active window.
I second this request. Not all GP users are fortunate enough to have a second display. The “disappearing” of the SmartView window really frustrates users. The fact that it falls behind ALL other windows after ANOTHER window is closed is contrary to all other window functions in GP. I understand that SmartView really runs independent of GP, but from a user experience, it should not require extra work on the user’s part to reactivate the SmartView window after simply closing another window that was opened using the built-in GoTo function.