What is typically happening is that SS.EXE prompts for user name and password if required but not supplied as command line arguments. Because the addin runs SS.EXE in the background to "hide" its details from the user, you do not see and cannot respond to its prompts for user and password.
Make sure that you have provided accurate values in the addin's properties file. One easy way to test is to run the SS.EXE program yourself (try "SS.EXE status") and answer its prompts with the values you intend to use. SS.EXE should be located in the \Win32 sub directory beneath the location specified for the SourceSafePath addin property.
Sometimes you are supplying the correct values but the addin is not "talking" to the correct Source Safe database so the values are correct but in the wrong context. See the discussion below about use of the SSDIR environment variable to ensure that SS.EXE is pointed at the correct database.
This typically occurs because the addin fails to initialize properly. Usually, this is due to a failure to find the SS.EXE program at the correct location relative to the directory specified in the addin's SourceSafePath property. SS.EXE should be found in the \Win32 sub directory beneath the location specified for the SourceSafePath addin property.
|Check to see that the "Force_Dir (CL)" entry is properly set (= Yes) in your Source Safe user's .ini file. The path to this file is determined by several factors. You may need to work with your Source Safe administrator to find it. On a simple install with the Source Safe database installed locally, look under the \Users sub directory beneath the location specified for the SourceSafePath addin property. For network installs, these files may be found on the file server.|
|If you are using a non-English version of Source Safe, the addin needs
to know. This is done via the SourceSafeLocale value in the addin's properties
file. By default, this is left blank which causes the addin to default
to English. For example, to ensure that support for a German version of
Source Safe is being used, make sure that the following line is in the
addin's properties file: "SourceSafeLocale=de" and the addin will expect
to see responses from SS.EXE in German. Otherwise, the addin expects to
see responses in English, gets confused, and gives up.
Another possibility along these lines is that you are using an internationalized version of Source Safe that is not currently supported. Current supports only includes English, German, and French. I do not know if Source Safe supports any other languages. If it does, it is fairly easy to add support so please contact me.
|The addin is not "talking" to the "right" Source Safe database. This
typically happens when the Source Safe database is installed on a file
server but you have installed it locally as well. It can also happen when
there are simply more than one Source Safe databases in use.
It is important to note that the Source Safe command line interface and the Source Safe Explorer use different means to "find" their Source Safe databases. The Explorer makes use of the system registry but the command line interface does not.
The key is to point SS.EXE at the correct location. This is most easily done in most cases by setting the SSDIR environment variable. From the Source Safe (version 6.0) docs: "Setting the SSDIR environment variable tells VSS where to find the SRCSAFE.INI file for the VSS server installation to which you want to connect." While not documented in the version 5.0 docs, I have found that this variable is supported.
|You have not selected the correct project for the addin to use or that project has not had its working directory properly set via the Source Safe Explorer. Go to JBuilder's Tools menu, then to the Source Safe Projects sub menu. There is a disabled menu item displayed which shows the addin's notion of the current Source Safe project. If you mouse-over this menu item, more information is shown in the JBuilder status bar. Verify that this is correct.|
|Versions of the addin prior to 1.13 do not properly handle some cases where directory/file names for project working dirs contain embedded spaces and are very long. Make sure you are using this version or later.|
Without constant use of SS.EXE to get at the "real" checkout status, the best that can be done is to "estimate" checkout status by mapping it to the file's read-only flag. JBuilder already does this but only when the file is actually open in an editor window. You cannot see this in the project view. I have already suggested this to Borland, you should too. Display of read-only status is really the IDE's job. Also, the case can be made that read-only status does NOT map to checkout status. Come on now, who among us has not flipped the read-only bit to work on a file prior to checking it out of the source control system?
The hang occurs because the SS.EXE program is asking for input to which you are not allowed to respond. This is similar to what happens with prompting for user ids and passwords (see above). Basically, multiple checkouts are not supported. My experience is that most Source Safe installations do not use this feature and it proves to be a pain to support since there is no easy way, via the command line interface to Source Safe, to know if multiple checkouts are enabled. So I just avoided the whole issue. You can use multiple checkouts and all is fine unless there is the need to merge. Sorry!