(or simply open FileScout WiFi-Sharing Options and press the "Check for Updates..." Button)
What's Fixed
Fix: A file that contained a space in the filename could not be downloaded from the BlackBerry® Device to your Webbrowser (Firefox)
This have been fixed in the new version. Thanks to F2 from the crackberry.com forum who was so kind and let me know the issue.
Fix: Upload of files to your Dropbox added accidently an additional <CR><LF> at the end of each file.
Well the "good" news is, that all your previously uploaded files does not get corrupted by the additional
<CR><LF>... On the other hand side this should not had happen in the first place and I am very
sorry that it took so long to identify & fix this issue.
If you wonder - What the heck is '<CR><LF>' ??? - This are two bytes: carriage return & line feed.
They represent a new line inside a text file - please don't start a rant about my simple explanation.
2012/03/16 - FileScout & FileScoutLite 2.9.0.5
What's Changed
WiFi-Sharing (via separate FREE Plugin that can be installed via the Options)
WiFi-Sharing allows you to up and download files to and from your BlackBerry Device via a modern Browser (like Chrome,
Firefox or Safari)
For Users of OS5 and above: The WiFi-Sharing Plugin comes with a WLAN SSID-Autostart feature! So you can configure the Plugin
to autostart the sharing service once your device is seeing (not necessarily connected to) a specific SSID (multiple SSIDs could
be configured). As soon as the Device does not have any connection to the SSID the Service will be automatically shut down (if you
are not using FileScout currently).
Improved Thumbnail-Cache Handling
Thumbnail-Cache can be now completely wiped (and re-created) from the Thumbnail Option
Small performance & stability fixes
2012/02/17 - FileScout & FileScoutLite 2.8.0.2
What's Changed
DevConEurope perceptions have been integrated (Thanks again D.Brown & G.Klaasen)
This year in Amsterdam I have learned few more things about the BlackBerry JavaVM and how
to behave as an app running in a BlackBerry device. After the event I have reviewed a lot of
my code and made use of the new knowledge.
Most of these changes are tiny little ones - which are hard to mention and explain - but
the overall handling of the app seams to be much smoother.
Just as one example here: When you rename a file and the complete file name will be marked.
Once you decided to delete the complete old name then cursor position display will be finally
correct in this new build.
Another example is for touch devices where it could had happen that selecting a sub folder
would had instantly marked a file in the directory that will be opened - this is finally solved
in v2.8.0.2.
ImageViewer
The image pre-loading and caching of the ImageViewer have been completely reimplemented and
should be now way more smoother and you should see the clock/hourglass way more seldom, if at all.
Image Thumbnail generation & loading
Also as consequence of the code review the original thumbnail loading and caching code have been
thrown over board and has been created from scratch - I really hope you will notice the difference
in the app.
Checking the 6MiB file size limit when sending file(s) via BBM™
Sending files via BBM™ is limited to a maximal file size of six megabytes. When you try
to send larger files in the current version of the BBM™ SDK simply nothing happens after you
have selected the recipients. In order to avoid this confusing situation FileScout is already
checking for the max file size limit and does not display the BBM™ in the 'Send To...' dialog
if the file size limit is exceeded.
2012/01/22 - FileScout & FileScoutLite 2.8.0.1
ZIP-Archive handling & performance
What's Changed
FileScout & FileScoutLite ZIP-file handing have been re-written
With the new v2.8.0.1 build there should be no limitation concerning the file size of ZIP-Archives
that you could browse or de-compress with FileScout (or FileScoutLite).
When you unzip a large (e.g. 100MB+) archive, please have in mind that you still hold a mobile device in
your hands (and not a PC or Mac equipped with a SSD). Most of the time that is required (to process an
ZIP-Archive) will be needed for the actual reading (of the compressed stream) and the writing (of the
de-compressed data).
The new build will also report almost instantly, if an archive can't be read by the application
(probably cause it is corrupted/broken).
Please note that even if most of the ZIP code have been rewritten FileScout is still not able to
read password protected archives - sorry.