private void doNewFolder() {
String name = JOptionPane.showInputDialog(null,"Enter new directory name", "Create New Directory", JOptionPane.QUESTION_MESSAGE);
//BUGFIX START
// if name is null, the user hit the "cancel"-button. in that case -> do not create folder
if(name == null) {
return;
}
//BUGFIX END
if(selectedTable.equals("remote")) {
name = remoteLocation.getText()+name;
viewer.rfb.createRemoteDirectory(name);
}
else {
name = localLocation.getText()+name;
File f = new File(name);
f.mkdir();
refreshLocalLocation();
historyComboBox.insertItemAt(new String("Created Local Directory: " + name),0);
historyComboBox.setSelectedIndex(0);
}
}
Status: fixed
Description:
Certain Files are shown as directories and thus can not be transferred.
Cause:
This was a funny one. The reason for this bug was, that all file attributes were checked, except for one: the attribute "ready for archiving".
Directory entries are not sorted. This really is a pain in the ass if you imagine a directory with thousand or more entries and you are looking for one specific file / subdirectory.......
Cause:
Well, there was simply no sorting mechanism implemented:
FTPFrame --> printRemoteDirectory(ArrayList a) looked like that:
public void printRemoteDirectory(ArrayList a) {
ArrayList files = new ArrayList();
ArrayList dirs = new ArrayList();
for (int i = 0; i < a.size(); i++) {
remoteList.addElement(a.get(i));
}
remoteFileTable.setListData(remoteList);
}
Solution:
FTPFrame --> replace printRemoteDirectory(ArrayList a) with:
public void printRemoteDirectory(ArrayList a) {
ArrayList files = new ArrayList();
ArrayList dirs = new ArrayList();
for (Iterator i = a.iterator(); i.hasNext();) {
String name = (String) i.next();
if(name.equals("[..]")) {
remoteList.add(name);
}
// blank before '[' is mandatory!
else if(name.startsWith(" [") && name.endsWith("]")) {
dirs.add(name.substring(2, name.length() - 1));
}
else {
files.add(name);
}
}
Collections.sort(dirs);
Collections.sort(files);
for (Iterator i = dirs.iterator(); i.hasNext();) {
String dirname = (String) i.next();
// blank before '[' is mandatory!
remoteList.add(" [" + dirname + "]");
}
for (Iterator i = files.iterator(); i.hasNext();) {
String filename = (String) i.next();
remoteList.add(filename);
}
remoteFileTable.setListData(remoteList);
}
Status: fixed
Description:
Directory contents are "double" displayed right after the initialization.
Cause:
I simply don't know.
Solution:
Was fixed as a side effect of the other adjustments i made.
Status: fixed
Description:
When creating directories and receiving files the layers or div tags gets resized and the action buttons (Receive, Send, Close etc..) becomes less and less visible > invisible. Then the only thing to do is to disconnect the Remote Session and restart it and then bring up the file transfer window again
Cause:
I have no idea.
Solution:
Adding a "this.repaint()" to actionPerformed(ActionEvent evt) in FTPFrame:
else if (evt.getSource() == sendButton) {
doSend();
this.repaint();
}
Status: Seems to be fixed (error didn't occur in my recent tests)
This is a weird behaviour and i am not sure why this happens. I am still not able to reproduce this behaviour. Sometimes the exact same transfers worked and sometimes they just didn't.
For now, i consider this fixed unless we see that error again.....
Bugs i am currently working on:
So far, nothing....
New features i am currently working on:
SSL
Transfer of directories
Bringing structure to the application:
So far:
- everything is in the default package
- huge classes having more than 1000 lines of code
Some remarks:
1.)
When i have more time i will update this thread with more information why this bug occured and how i fixed it.
2.)
Is there an official bugtracker available? I didn't find anything like that on this website....
Last edited by buggybunny on 2007-10-23 13:43, edited 9 times in total.
I fixed the printRemoteDirectory() function so it takes the uppercase/lowercase strings into account.
The sorting is now also done on the Local file list.
// jdp check for FILE_ATTRIBUTE_DIRECTORY attribute bit
// note that we're looking at a little-endian value in a big-endian world
if ((dwFileAttributes & 0x10000000) == 0x10000000)
{
fileName = " [" + fileName + "]";
remoteDirsList.add(fileName); // sf@2004
}
else
{
remoteFilesList.add(" " + fileName); // sf@2004
}
We have connected to Remote machine using Java Viewer with Restricted colors 64 .After Connection is established we have seleted Full colors in Restricted colors drop down and observed that the viewer is Flashing continuously.
Anyone else see this? Is there a fix? I've seen this happen when you enable screen recording as well, even in 64 color mode.
hi,
i have installed 1.0.4 rc16 for using filetrasfer via javaviewer but only recycler and system volume information are known as directory.
i have a windows 2003 sp.2 stand-alone server with problem and another windows 2003 sp.1 in domain without problem.
where problem?
thanks for advance.
Last edited by lsorato on 2008-07-02 10:15, edited 1 time in total.
flyfishr64 wrote:We have connected to Remote machine using Java Viewer with Restricted colors 64 .After Connection is established we have seleted Full colors in Restricted colors drop down and observed that the viewer is Flashing continuously.
I have an other effect. If I change the Options after connection established, the screen on the viewer freezes but the manipulations take effect on the remote machine. That meens that mouse and keyboard are processed but the screen won't be updated.
Hi,
If you change the Java viewer from Full colour to 8bit colour and back again, updates stop working. This is because viewer.options.oldEightBitColors doesn't get updated in this case so fullUpdateNeeded always gets set to true.
The following patch fixes it.
I've installed and configured UltraVNC 1.0.9.5 to use new MS Logon. It's working very well using UltraVNC viewer but not with the Java Viewer.
The Java Viewer was supposed to support MS Logon since 2004!
[topic=850][/topic]
So I looked in the Java Viewer source and found out that MS Logon is enabled only when the server minor version number is 4. The server's version for 1.0.9.5 is 3.8. So I changed the line 416 in VncViewer.java file from:
I've installed and configured UltraVNC 1.0.9.5 to use new MS Logon. It's working very well using UltraVNC viewer but not with the Java Viewer.
The Java Viewer was supposed to support MS Logon since 2004!
[topic=850][/topic]
So I looked in the Java Viewer source and found out that MS Logon is enabled only when the server minor version number is 4. The server's version for 1.0.9.5 is 3.8. So I changed the line 416 in VncViewer.java file from:
