jabirulo came up with a solution for the Ringhio error. If the word 'to' is in the description you have to put the entire text in quotes.
It's not a solution at all, but rather a temporary workaround - because now you register your app with a quote-enclosed description, which is then picked up by any program that can display the description (Exchanger is an example). This is not the way to go.
Before the Ringhio bug gets fixed, why not change the description so that it doesn't include the word "to"? After all, Workbench Explorer is more than just "a better way to browse drawers".
Before the Ringhio bug gets fixed, why not change the description so that it doesn't include the word "to"? After all, Workbench Explorer is more than just "a better way to browse drawers".
I was about to suggest the same.
"An advanced file manager" or some such would be a more professional description and not trigger the bug.
@mritter0 Probably i found somehow related problem to the slow-resize and sometime-non-responsive on close-button:
To reproduce: 1. run wex 2. move window to _another_ part of screen. Like it was at top left, but move it to bottom right (I do tests on 1440x900 btw). 3. press "iconify" : you will notice BIG DELAY. 5 seconds maybe, maybe more. If you move window a lot , then delay is more.
So, you also can check the same and for close button:
1. run wex 2. move window anywhere (just to another side of screen) 3. try to press close gadget => huge delay.
I think, it the same problem which cause "slow resizing" of window.
To note, that if you didn't move window at all, then there is no delays when press close button or iconify. It all happens once you move a lot window.
You also may try, to resize it few times before moving, just to be 100% sure you can reproduce that bug.
Some people have mentioned that WEx is slow responding to window moving and resizing. I don't get any of that. So I made a short video using WinUAE (not my X5000) to show it working on a "slow" system.
@mritter0 Obviously there must be some difference between your system & those people reporting the problem. Maybe it's that you have Prefs/GUI > Controls > "Drag/Resize window with content" UNticked?
edit: I see what Kas1e means. Although I imagine the above setting still reduces the impact of it.
1. You use there VERY small resolution. Probably 800x600 ? or 1024x768 ? That way you may not see problems very much.
2. Resizing of window the same slow for you on video ! Not _that_ slow, but you can see yourelf from your video, that once you resize the window, evertyhing "wait a little", and only then, regroups, and only then, resizes.
Its very visibly for example from 15 to 21 seconds of video. And its the same on x5000. The same slow resizing. And i see it only in Wex, all other programms didn't resizes that slow.
And i am sure, that this resize problem, can be because of the same problem i describe in previous post : slow responce on gadgets, RMB, etc, etc. By slow i mean 5-10 seconds pause.
Now, let's forgot for slow resizing for a moment, and just check plz that:
Just try to reproduce steps as i describe:
1. setup big enough video mode (i use 1440x900). 2. move (not resize! just move!) your wex window to any other part of screen. 3. press "close gadget".
As result , you will have delay for about 5, or 10 seconds. The same for iconify, the same for RMB.
Some people have mentioned that WEx is slow responding to window moving and resizing.
I am one of them. Resizing/refreshing GUI is very slow on my system, and I'm also getting the problem somebody has mentioned earlier: slow program start-up, and menus being attached only after a delay.
I can't see inside your code so I don't know what exactly you do at GUI initialization time. But I'd like to mention that with GUIs like yours, where a lot of objects are used (dozens of bitmap images, for example), it is doubly important to follow my ReAction recommendations and use the class pointer in all NewObject() calls, instead of macros or the public class name; see section 3.2 of the linked document. It really makes a big difference on low-end systems.
Perhaps you already do this (well done, then!) and the slowdown comes from something else; I just wanted to say what my general findings are, with a good-hearted view to improving the programming standards around here.
well, resizing (redraw) actually looks quite slow in your video. please activate the live window redraw while resizing in gui prefs. isn't this active per default these days haveing fast graphic cards?!
One would guess that the program reopens its prefs file repeatedly, in response to a continuous flow of IDCMP messages.
If you look at the first page of this topic you will see I reported that problem and got a 'reason' from the author. I just tested again by moving the window around the perimeter of my screen and then to the center of the screen. The first time Snoopy showed 4627 open/close of the prefs in ENVARC: and the second time it was 11501 open/close operations. After all that activity there was no change to the Workbench Explorer prefs. Since I don't have autosave activated in the prefs, I don't think it should be altering the prefs in ENVARC: anyway. Regardless of the reason the author gave, I think somethings wrong with that much disk access to change nothing.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Regardless of the reason the author gave, I think somethings wrong with that much disk access to change nothing.
Indeed I had overlooked your earlier post and Mark's reply in this thread. That being said, whatever WEx does behind the scenes when the window is moved is very unusual. Considering the fact that a file manager is central to many users, it must be a slick piece software with as little overhead as possible.
I'm sure Mark will find a better solution quite soon.
One thing to think off in handling the window event loop is that you will receive a lot of certain messages, particular window change, resize, moved etc. Rather than deal with these individually you should set a flag and deal with that flag once the queue has been cleared.
eg psuedo code:
while not done
{
wait
BOOL windowchange = FALSE
BOOL resize = FALSE
while event left in queue
{
if IDCMP_NEWSIZE resize = TRUE
Other stuff
}
if resize = TRUE handle resize
if window changed = TRUE handle change
}
@jabirulo Sounds like you found the main cause of the slow resizing/moving.
While this could no-doubt be vastly optimised (e.g. updating EnvArc only once per second if there has been a change), IMHO it makes no sense to be doing this AT ALL on an Amiga. It's just not the way Amiga software works. (And what happens if your Amiga crashes while moving/resizing WEx? Unexpected disk corruption/validation. Not good.)
(Note: I am a BIG fan of programs remembering the last state they were in (which not many Amiga programs do), but only by having them save it when the program closes.)
Better to update EnvArc's window size/pos info ONLY when the user Snapshots the window OR (maybe) quits the program.
@mritter0 I discovered another bug in WEx (v1.0). It fails to unlock the following 3 files in the "Images/TBImages" folder: folder_userfiles folder_userfiles_g folder_userfiles_s
This prevents your installer from updating WEx (if you have already run WEx), as it cannot update those files, and so fails with an error message.
I found the cause of the slow resize/move. Totally looking me in the face the whole time. I didn't experience because I didn't have the same GUI settings enabled. Super easy fix.
@ChrisH Weird. I will look into that. All the images load the same....
@all v1.2 will be released real soon.
Workbench Explorer - A better way to browse drawers
Weird. I will look into that. All the images load the same....
It won't be the loading but the disposing, perhaps you accidentally skipped disposeing that set. Or less likely but possibly accidentally loaded them twice?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
