Toad World® Forums

RE: RE: Toad : Slow response in "open" dialogbox on syncronised folder

Hey Sam,

Just as a quick follow-up to Norm’s post:

Norm is correct. It is the default behavior of a standard open dialog to enumerate through network resources in order to populate the LHS tree. Sometimes
this happens in background threads (resources slowly getting added to the tree); however, sometimes it also appears to freeze when you select a network node in an open or save dialog and it has trouble resolving and/or enumerating that resource. Once it’s
been cached, it’s usually fine. This is a Windows thing. Since the LHS tree was added with Vista and higher, it’s much more noticeable than when we were running in Windows XP.

We noticed the same kind of problem within the components we were using for our dialogs during the beta cycle, and decided to put in some code to help alleviate
that issue. As a result, Toad’s dialog shouldn’t enumerate through network shares in the LHS tree unless it’s a local or mapped drive. If you’re trying to access the share via a UNC path, I’d recommend mapping the share and disabling the conversion to a
UNC path in Toad’s options. Mapped drives are generally quicker because [theoretically] Windows has already made a successful connection to them before the open or save dialog is even shown.

If it’s still a problem, I suspect it’s probably related to the issue that was recently fixed. When Toad navigates to a folder, each item in that folder (whether
it’s a file or subfolder) is compared to filtering logic in order to determine if the item should be shown. On local drives, this isn’t a problem; however on networked folders (especially those with large number of files and/or folders), we noticed situations
where performance could be affected. This has been addressed for the patch, as well as for the next 12.1 beta. Upon looking at my version history, it didn’t quite get fixed in time for the current beta, so you will need to wait for the next beta, which should
be later this week. If you’re not already on the beta program, I’d highly recommend joining. Not only will you be able to test drive the latest current development efforts within Toad, you’d be able to provide valuable feedback during the development cycle
itself, and help shape Toad into what you (the users) need.


From: Norm [TeamT] []

Sent: Wednesday, July 17, 2013 12:36 PM


Subject: Re: [Toad for Oracle - Discussion Forum] RE: Toad : Slow response in “open” dialogbox on syncronised folder

Re: RE: Toad : Slow response in “open” dialogbox
on syncronised folder

Thread created by Norm [TeamT]

Afternoon Sam,

On 17/07/13 16:59, SamWiddowson wrote:

My colleagues and I are experiencing the same issues. Toad “hangs” for

10-20 seconds when opening the save or open dialog boxes. Also on


Do you see this sort of thing in other applications as well? I think

it’s a Windows thing to be honest. I see it myself in my text editor

when I have mapped network drives. I think, but I’m not 100%, that when

a open file dialogue is first created, it has to enumerate all the

attached drives and folders etc (at least at the top level) before it

can be displayed.

It only freezes when the default folder (i.e. the last saved location)

is on a network drive - now when it’s on a local drive. Other

applications don’t freeze when opening save dialog boxes in the same


See above. I think your problem is with the enumeration of the network

attached drives. The locals one(s) should be quite speedy. Try,

temporarily, disconnecting the network drives to see if it makes any


It’s absolutely infuriating, as we need to use the network location to

save our work.

Agreed, it is infuriating, but I see the same problem in other

applications. My worst one is (rather was) Microsoft Word. It took ages

to open a file save or file open dialogue.


Norm. [TeamT]

To reply, please reply-all to this email.

Stop receiving emails on this subject.

Unsubscribe from Toad for Oracle - General
notifications altogether.

Toad for Oracle - Discussion Forum

this post as spam/abuse.