-
Hi,
I try to understand, what is happing in my code (on OS 5.x)... Actually I do understand your words - but in the combination with the source code it does not makes sense at all...
Just allow me some additional questions:
When you have opens 'system' once and your file list does not get updated - I assume, when you click then on 'SDCard', that then also "nothing" happens?
Can you press 'ESC' till you see in the title back just Dir: '/' ?
When you are back in Dir: '/' can you then open the other two root folders?
The reason why I am asking all these silly questions is here is what my code is doing:
1) setting the Title text of the Window
2) remove all entries from the result list
3) reading the file system
4) create a new list
What I understand from your observation digitalb0y is, that the "new" Title will be set from Dir: '/' to Dir: 'system/' but then already the list will not be cleared...
OR
it will be cleared, but the application is reading again the same content from the "system" folder, that was already read as "roots"...
Actually I do not see any reason, why the code should cause a behaviour like you described earlier... When there is a problem with reading the "system" folder, then I would expect, that the Title will be set, the list will be cleared and then will not be filled again [cause while reading of the folder fails for what ever reason]... And since I assume opening "SDCard" or "store" will work smooth like silk, there is no reason to believe, that clearing the items from the list could be any problem...
Might be that the list is cleared - but the screen does not get updated...
this is really strange - be so kind and PM me your eMail address - so I can send you additional FileScout builds for some tests...Last edited by emacf1; 10-09-09 at 03:53 AM.
10-09-09 03:45 AM - some sort of good news - finally I have understood my own code again
finally I am able to understand, what is going on - and the behaviour you have described is reasonable... I "think" I have found something, that might could make the system folder readable again - if that does not work there will be at least a message, that the folder could not be read... now I have to wait for feedback from OS 5.x users.10-10-09 04:17 AM - Thanks Matthias!
It seems you pinpointed the problem. I now get your error message instead of the endless title loop. And your guess seems to be correct about RIM locking down viewing access to the System directory in OS 5. It's not available from the built-in file browser either.
I'd have no problem with this since it's probably a lot more secure that way, but it's too bad they insist on making so many extras so difficult to delete. 128MB is small for a system volume to begin with, so I don't really need BBFileScout to do much moving and copying TO the System volume, but it sure was a handy tool for getting stuff OFF of the system volume for maximizing usable resources. Now it looks like our only option for removing extraneous stuff will be to connect the 'Berry to a computer and pare it down with CrackMem, CrackUtil, BBSAK, etc.
...That is unless you've still some wizardry up your sleeve!10-10-09 05:40 AM - Well it's quite sad, that RIM have decided to completely block the access to this folder in the API - IMHO it's my device and I should be allowed to decide what is in the filesystem and what is not... but well right now I am not forced to use the 5.0 - of course it looks nicer - but since my Storm already struggles with the 4.7 OS from time to time (being slow) I just can assume that the extra effects will eat more CPU power - but i do not want to start and "which OS is better" discussion now...
I hope even without access to the System folder FileScout remains a useful tool for everybody - Probably there have been plenty more folders that are completely hidden in the past to which we never had access...
Right now I don't think so... in the API there is a function that give you a list of all files in a folder... In the case of the system folder on the OS5 this method does not return a list at all [in the past I had the case, that simply an empty list was returned - but this is not the case here]. So I do not have any clue what else can I do... I am sorry but this looks like a dead end....That is unless you've still some wizardry up your sleeve!
Matthias10-10-09 06:45 AM - So selecting the "check for updates..." Item from the list will cause the "context menu" to appear??? -> that should happen, when you press the #Menu Button - but not when you hit ENTER once the item is selected... that is a really wired behaviour Are there other OS 5.x users that can confirm this?
10-10-09 12:46 PM - yes that is happening. really strange...So selecting the "check for updates..." Item from the list will cause the "context menu" to appear??? -> that should happen, when you press the #Menu Button - but not when you hit ENTER once the item is selected... that is a really wired behaviour Are there other OS 5.x users that can confirm this?
can soneone else confirm this glitch10-10-09 02:39 PM - I can also confirm this I'm running .238. It pulls up the context menu. Also does that mean I can't change my folder icons any more if I'm running 5.0?So selecting the "check for updates..." Item from the list will cause the "context menu" to appear??? -> that should happen, when you press the #Menu Button - but not when you hit ENTER once the item is selected... that is a really wired behaviour Are there other OS 5.x users that can confirm this?
Thanks10-10-09 07:24 PM
