XYplorer Beta Club

admin wrote:OK, ZipFolder technology is a shell function and all shell functions fail when paths get > 260.

So you rely on system function for zip support?
Wouldn't be easier to use something like an unzip.dll, sister of the upcoming (I suppose) unrar.dll and un7z.dll, and build modularly upon these the archive support?

The can (of worms) is opening...

Lol
Please tell us why. I'm not a professional programmer, but I coded in the past and I do understand the basics of what is gonna create chaos in a coding environment.

Can of worms in the sense of endless wishes. Let's go step by step. Now we have basic zip support. Fine. Now back to the roadmap: Breadcrumbs!

admin wrote:Can of worms in the sense of endless wishes. Let's go step by step. Now we have basic zip support. Fine. Now back to the roadmap: Breadcrumbs!

I agree Don, XY can claim basic Zip support now. I guess you realized this was necessary to stop the whining.
Look forward to more interesting stuff.

Sure, I was just saying. Speaking for myself, I will find breadcrumbs more useful

But I had to express my feelings about a more-than-basic support to archive files. It's not a wish, I didn't wish anything as a matter of fact, I just said that a more future-proof and improvable archive support would have, imo, better be built upon code that doesn't rely on system function. Especially given that zip, rar, 7z and iso (these are the big four) are all formats that have nothing to do with the underlying OS. The juice of previewing such formats is parsing correctly their TOCs (mainly the full filename), along with additional data like dates and attributes. Since XY supports overlong paths I imagine an archive parser made by Don would have fit great in the general XY picture and not led to the issue we saw this afternoon.

Can not quote Marco enough. But, as in Marco's case, this is an unwish - return to breadcrumbs now, go to vacation and rethink the compression support there.

Marco wrote:Sure, I was just saying. Speaking for myself, I will find breadcrumbs more useful

But I had to express my feelings about a more-than-basic support to archive files. It's not a wish, I didn't wish anything as a matter of fact, I just said that a more future-proof and improvable archive support would have, imo, better be built upon code that doesn't rely on system function. Especially given that zip, rar, 7z and iso (these are the big four) are all formats that have nothing to do with the underlying OS. The juice of previewing such formats is parsing correctly their TOCs (mainly the full filename), along with additional data like dates and attributes. Since XY supports overlong paths I imagine an archive parser made by Don would have fit great in the general XY picture and not led to the issue we saw this afternoon.

Agreed and I could, and even should, and one day probably will, do it (although relying on 3rd party DLLs is not XY-ish).

admin wrote: Agreed and I could, and even should, and one day probably will, do it (although relying on 3rd party DLLs is not XY-ish).

Does that mean, that MS / Windows is 2nd or 4th party?

admin wrote:Agreed and I could, and even should, and one day probably will, do it (although relying on 3rd party DLLs is not XY-ish).

As long as the 3rd party DLL's are free and not part of a paid package, I don't see any issue with it...there are plenty of applications that rely on separate party DLL's due to license restrictions or similar and if these DLL's are usually found anyway on those systems that desire those functions due to the other app's already being there, I don't see any problem...I've got a PDF utility that requires Ghostscript installed and MP3 utilities that require LAME encoder and that was ok with me.

j_c_hallgren wrote:As long as the 3rd party DLL's are free and not part of a paid package, I don't see any issue with it...

Fundamentally

1. Don wants total control over his creature
2. The license of the dll's could be a problem, since XY is paid and closed source. I don't know if GPL dll's would be ok, I know BSD ones would be ok for sure.

Marco wrote:1. Don wants total control over his creature

Oh, believe me...I KNOW that! But there are some rare cases where allowing usage of external DLL's could greatly enhance the options available to XY with no coding effort required, esp if competing products use the same DLL, such as the 7z one...and this may be one of those.

2. The license of the dll's could be a problem, since XY is paid and closed source. I don't know if GPL dll's would be ok, I know BSD ones would be ok for sure.

I don't see the problem becuase some other app's require you to install the DLL's from the DLL author/vendor source...they don't include it directly, but just give links to where it can be found so no actual code is included.

j_c_hallgren wrote:

admin wrote:Agreed and I could, and even should, and one day probably will, do it (although relying on 3rd party DLLs is not XY-ish).

As long as the 3rd party DLL's are free and not part of a paid package, I don't see any issue with it...there are plenty of applications that rely on separate party DLL's due to license restrictions or similar and if these DLL's are usually found anyway on those systems that desire those functions due to the other app's already being there, I don't see any problem...I've got a PDF utility that requires Ghostscript installed and MP3 utilities that require LAME encoder and that was ok with me.

The main problem with (free, but also paid) 3rd party stuff is simply this: It usually has bugs, bugs that I have no chance to fix. And it has limitations, limitations that I have no chance to get rid off. This will sooner or later drive me into depression.

admin wrote:This will sooner or later drive me into depression.

Then, after the coffee and omelet emoticon, we need also the Xanax and Prozac ones

Marco wrote:

admin wrote:This will sooner or later drive me into depression.

Then, after the coffee and omelet emoticon, we need also the Xanax and Prozac ones

I could use them NOW!