VanDyke Software Forums

VanDyke Software Forums (https://forums.vandyke.com/index.php)
-   Secure Shell (https://forums.vandyke.com/forumdisplay.php?f=15)
-   -   How to make SecureCRT *not* close when last tab is closed? (https://forums.vandyke.com/showthread.php?t=5372)

tbessie 03-22-2010 02:20 PM

How to make SecureCRT *not* close when last tab is closed?
 
Hello there...

So I want tabs to close when the session is closed, but I don't want SecureCRT to exit when that last tab/session is closed. I don't see a setting for this anywhere, however.

Is this doable?

- Tim

rtb 03-22-2010 03:04 PM

Hi Tim,

It is not currently possible to close the last tab in SecureCRT. As this is the case, if you can describe in detail what steps you are manually taking, we may be able to help you find a solution to the problem.

Would you post the exact steps you are taking which result in SecureCRT closing?

If you are using a script, would you post the script you are running?

tbessie 03-22-2010 05:47 PM

Quote:

Originally Posted by rtb
Hi Tim,

It is not currently possible to close the last tab in SecureCRT. As this is the case, if you can describe in detail what steps you are manually taking, we may be able to help you find a solution to the problem.

Would you post the exact steps you are taking which result in SecureCRT closing?

If you are using a script, would you post the script you are running?

Hello rtb...

I'm not using any scripts. The thing is, when SecureCRT starts, there are no tabs open. It seems logical, given that, that you should be able to close the last tab (so that there are no tabs open), and yet SecureCRT not shut down, doesn't it?

The "steps" I'm taking are merely opening a bunch of sessions in tabs, and, as I'm done with each one, logging out of the session (a regular Unix logout). Let's say for argument's sake I've open 5 sessions in tabs, each of which is a connection to 1 group of servers.

Now I want to open connections to a different group of servers... so I log out of all the current sessions, thus closing the tabs (as I've selected Terminal->Close on disconnect). If I close the last tab, SecureCRT itself closes. This means if I want to open the 2nd set of sessions in my example, I'd have to keep one last tab open, open the 2nd set of sessions, then close the last remaining connection to the 1st set of sessions.

This kind of shuffling seems a little silly for a reasonably expensive program.

Why MUST SecureCRT close when the last session tab is closed, if SecureCRT is able to be open when it starts up without any session tabs open?

- Tim

rtb 03-23-2010 10:58 AM

Hi Tim,

I can tell by your wording that you are pretty frustrated by the current behavior you are seeing in SecureCRT. Here's some historical background to help explain SecureCRT's current "Close on disconnect" behavior.

The "Close on disconnect" option existed in SecureCRT since it's early days -- long before SecureCRT had any support for tabs. It was originally implemented as a response to requests from SecureCRT users who wanted the application to close as soon as the underlying ssh/serial/rlogin/telnet/etc. connection was closed.

When support for tabs was implemented in SecureCRT back in mid 2004, it was decided that the existing "Close on disconnect" session option should close the appropriate tab, and ultimately close the application if the last tab was disconnected. This interaction decision helped to maintain consistency in the existing "Close on disconnect" behavior which long time SecureCRT users had come to expect.

Even though we strive to maintain consistent behavior that long-time users have come to expect, it doesn't mean that we can't add an option to modify this behavior. I have created a feature request in our SecureCRT development database to add just such an option. Should a future release of SecureCRT have the ability to close the last tab rather than the entire application on disconnect, we will post to this forum thread. If you would like to be notified directly, please complete and submit the form at the following location:
Submit Feature Request

tbessie 03-24-2010 12:23 AM

Quote:

Originally Posted by rtb
Hi Tim,

I can tell by your wording that you are pretty frustrated by the current behavior you are seeing in SecureCRT. Here's some historical background to help explain SecureCRT's current "Close on disconnect" behavior.

The "Close on disconnect" option existed in SecureCRT since it's early days -- long before SecureCRT had any support for tabs. It was originally implemented as a response to requests from SecureCRT users who wanted the application to close as soon as the underlying ssh/serial/rlogin/telnet/etc. connection was closed.

When support for tabs was implemented in SecureCRT back in mid 2004, it was decided that the existing "Close on disconnect" session option should close the appropriate tab, and ultimately close the application if the last tab was disconnected. This interaction decision helped to maintain consistency in the existing "Close on disconnect" behavior which long time SecureCRT users had come to expect.

Even though we strive to maintain consistent behavior that long-time users have come to expect, it doesn't mean that we can't add an option to modify this behavior. I have created a feature request in our SecureCRT development database to add just such an option. Should a future release of SecureCRT have the ability to close the last tab rather than the entire application on disconnect, we will post to this forum thread. If you would like to be notified directly, please complete and submit the form at the following location:
Submit Feature Request

Hi again, Todd...

Thanks for the very complete description of How Things Came To Be. :-) I understand that the history of an app contributes a ton to its current incarnation, and you don't want to add every feature in the book that someone might think is useful, lest your app bloat out of control.

Still, I think the option of not having SecureCRT close on last tab close (as a non-default option, of course, so as to please long-time users) would be a very useful thing, at least given my own usage patterns.

I've been almost entirely a user of Putty all these years, but, not being happy with the available "Tabbed Putty" variants out there, decided to buy SecureCRT, especially given my last few roles that have added server administration to my regular programming duties - connections to dozens of servers begs for the use of tabbed windows. :-)

In any case, I hope it's a feature you add sooner rather than later. I can work around it, of course, using multiple SecureCRT windows, but it would be great if I didn't need to do that.

Thanks again for your explanation.

- Tim

rtb 03-24-2010 10:31 AM

Hi Tim,

I am glad that I could help explain SecureCRT's current behavior. We will post to this forum thread if a future release of SecureCRT has the ability to modify the way that the last tab is closed.

tbessie 03-24-2010 12:50 PM

Quote:

Originally Posted by rtb
Hi Tim,

I am glad that I could help explain SecureCRT's current behavior. We will post to this forum thread if a future release of SecureCRT has the ability to modify the way that the last tab is closed.

Thanks! By the way, one other thing that's a little tweaky is that you can't create a Session called 'default'. It *appears* from my programmer's eye that the 'default' session that's used as a template for others is merely a regular session, named 'default' that is hidden from the user in the session list.

This may have been convenient to program, but it also 1) limits the user's choice of session names, and 2) produces inconsistent program behavior, since the default session is not in the list, yet it exists anyway and the user is warned they can't create one with that name. There's no real need to have implemented it this way - you could have made the default session visible but undeletable, or given it no name at all and kept separate from other sessions, so that users can name a session 'default' if they want to.

Just another suggestion to put in your list. :-)

- Tim

rtb 03-24-2010 03:17 PM

Quote:

By the way, one other thing that's a little tweaky is that you can't create a Session called 'default'. It *appears* from my programmer's eye that the 'default' session that's used as a template for others is merely a regular session, named 'default' that is hidden from the user in the session list.
Hi Tim,

This isn't quite accurate. The default session is *not* a regular session. It is a template that is the foundation from which the Quick Connect dialog, and all ad hoc sessions derive their settings. It is accessible for editing from the General / Default Session category of the Global Options dialog. It is not listed in the Connect dialog because of the potential for cognitive friction. The Connect dialog is reserved for user defined sessions.
Quote:

1) limits the user's choice of session names
You are correct. Because the default session has been placed in the Session folder, there is one restriction placed on the name of a session in the root of the Sessions folder in the Connect dialog. You are welcome to use different variations of the word "default" in the root of the Sessions folder in the Connect dialog, or you can name a session "default" in a user created sub-folder in the Sessions folder of the Connect dialog.

It is interesting that you bring this up. This is the first time I can find since 1998 (when SecureCRT first started using the Default.ini file) that someone has requested that this behavior be changed.

Perhaps what you are saying is that this behavior is not adequately documented. If SecureCRT's help had better Default Session documentation including the restriction of having a user defined session named "default" in the Sessions folder of the Connect dialog, would this additional documentation have been helpful?

tbessie 03-25-2010 02:58 AM

Quote:

Originally Posted by rtb
Hi Tim,

This isn't quite accurate. The default session is *not* a regular session. It is a template that is the foundation from which the Quick Connect dialog, and all ad hoc sessions derive their settings. It is accessible for editing from the General / Default Session category of the Global Options dialog. It is not listed in the Connect dialog because of the potential for cognitive friction. The Connect dialog is reserved for user defined sessions.

You are correct. Because the default session has been placed in the Session folder, there is one restriction placed on the name of a session in the root of the Sessions folder in the Connect dialog. You are welcome to use different variations of the word "default" in the root of the Sessions folder in the Connect dialog, or you can name a session "default" in a user created sub-folder in the Sessions folder of the Connect dialog.

It is interesting that you bring this up. This is the first time I can find since 1998 (when SecureCRT first started using the Default.ini file) that someone has requested that this behavior be changed.

Perhaps what you are saying is that this behavior is not adequately documented. If SecureCRT's help had better Default Session documentation including the restriction of having a user defined session named "default" in the Sessions folder of the Connect dialog, would this additional documentation have been helpful?

Maybe - I'll have to take a deeper look into what clues that there is such a session called 'default' exists (other than the Global properties "Default Session" button). If there's a list of sessions and one's called 'default', and the user can see it alongside the other sessions, that should be enough. If that's the case, my only confusion would be the lack of it showing in the Quick Connect dialog, but perhaps I am misinterpreting the function of the Quick Connect dialog; I had assumed it would contain all created Sessions.

Anyway, again, I'll look at it again to get a reality check. Thanks for the interest! :-)

- Tim

smudge 05-19-2011 10:12 PM

Since it would be bad form to submit a duplicate feature request, does your request system have any kind of weighted system so that multiple requests for a feature get a higher priority? If so, please add another request for the original feature request of an "Except for last session" suboption to the "Close session on disconnect" option.

Thanks

miked 05-20-2011 09:01 AM

Hello smudge,

Yes, the number of requests is one factor. I have added your post, and we can will post a follow up message if implemented. For direct e-mail notification, please let us know and refer to forum thread 5372.

Olaf van der Spek 05-25-2011 04:53 PM

I don't use Close on Disconnect, but I'd like to be able to close the last tab manually.

miked 05-25-2011 05:11 PM

Thanks Olaf,

I've recorded your request and we'll post a follow up message if we add the ability to close the last tab! :) Please let us know and refer to forum thread 5372 if you'd like to receive e-mail notification as well.

Maureen 01-03-2012 04:33 PM

The ability to close the last tabbed session, but leave the SecureCRT window open has been implemented in a pre-beta version of SecureCRT. If you would be interested in trying it, please send e-mail to me at Maureen.Jett@vandyke.com.

Maureen

balmydrizzle 04-06-2012 04:04 AM

my workaround
 
I just add a profile with ssh2 to 127.0.0.1 and goto options-global option-general-default session, click 'auto session' radio button, click add button to add this profile. In this way, It will leave a tab there, so the problem is avoid.

jdev 06-10-2016 03:46 PM

For those just joining us:

As of SecureCRT version 7.3 B1, there's an option in Global Options' Terminal category named "Exit when last session is disconnected"

If this option is enabled, SecureCRT will exit (the main window will close) when the last remaining tab is closed. If it's not enabled, the SecureCRT window will remain open even if the last tab itself closes.

This allows individuals to enable "Close on disconnect" in session options, turn/leave off the "Exit when last session is disconnected" global option, and not have to worry about the main SecureCRT window closing if the last tab gets disconnected.

FYI.


All times are GMT -6. The time now is 08:25 PM.