missing path variable in user commands

So there was no need to modify the dcpp/*?

Do you know if similar variables are available in windows dc++ (or other clients)? And if they are, the names should be the same.

--RZ

No, no need for a modification on dcpp/* - it was only those cr/lf's. Apparantly I removed them because they were annoying me. I checked by getting the latest trunk and comparing my older dcpp/DirectoryListing.cpp with the newer one.

There are similar variables available in windows dc++, but they are all different. I've compared them recently:

%[mynick] = %[myNI]
%[nick] = %[userNI]
%[file] = %[filePH]%[fileFN]

the last one is with my patch applied, otherwise it's just %[fileFN] - but the windows variant is (iirc) containing the full path.

Correct me if I'm wrong, but with your patch the behavior between linuxdcpp and dc++ will differ. DC++ has the following:

%[file] = %[fileFN] = path + filename

So DC++ has only one variable to hold both pathname and filename. While your patch will separate path and filename into separate variables:

%[file] = %[fileFN] = filename
%[filepath] = %[filePH] = path

DC++ doesn't seem to have %[filePH] and %[filepath] or any other variable to hold just the path. Of course, the current behavior in linuxdcpp is wrong since it only contains the filename, but shouldn't we fix that by adding the path to %[file] and %[fileFN] instead of creating new variables? Are these other variables common in other clients is that why you included them?

I didnt want to seperate the path and filename in the first place, but I didn't want to mess with the current variables, so I just added the path variable. Besides that, I could think of things that it might be useful to have those seperated. However, making fileFN containing the path and filename is an easy thing to fix.

Only variable that would be missing is a Magnet link then.

I don't know if other clients have these variables, my guess would be that they have.

I would accept a patch to add path to file and fileFN to stay consistent with DC++. If you feel like adding the magnet one, that sounds good as well.

New patch added

Disregard that one, I forgot to clean up

Ok, cleaned the patch up and this one also contains my changes to include %[fileMN] for magnet links.

Crashes if you right click a dir in sharebrowser. You need to check if it is a file or a dir before casting.

Noticed that too and changed it already. But I'm a bit stuck now, because if I want to get the path for the directory, it end up with path/to/directory/directory in fileFN. And since my programming skills are a bit limited, I don't know how to fix that at this moment. I attached my changes in sharebrowser.cc

Since you were stuck, I went ahead and made the fix to sharebrowser by getting the path of dir->getParent(). I also added the path to the dirView user commands since that was missing. Thanks for the patch. Your first, but hopefully not your last. :)

Great, learned another thing. Thanks for your help. I'll be on the lookout for other things that I might be able to fix. :)