Bugs/Sugg for v1.4.2 (Build 830) NewSession Options / Schedule Clock

[secamela]

First Congratulations I'm a happy user on day 10 of 30 days evaluation period. And I succesfully downloaded 5+GB on my first 4 days, from wich I took the following experiences.

I've detected a not-so-desirable behaviour of New Sessions and it's Options|Preferences.

I tried it in particular with Options|Preferences|Transfer|Mode and Options|Skip List. In the last New session Window open, I changed these parameters, then all previous windows were affected, provoking unwanted effects in rest of pending queues.

I believe that if you allow New Sessions, each one has to have its own Preferences (inherited by default off course from it' s Father's Process or Default properties (tbe) -this sounds like class inheritance and so-)

Another less important little bug may be the clock appering in the Tools|Schedule it's a twelve hour clock may it be a 24h one, or at least show the am pm suffix or just better be adjusted to the default windows format for each user and location.

----------
Should these comments qualify myself for the Suggestion of the Week's prize of a free registration code
----------

[bigstar]

This behavior is by design. please read the following post for more information on how FlashFXP works and how to disable this behavior.

http://www.flashfxp.org/~forum/showt...SaveOnExit%3D1

[secamela]

Well let's talk about SaveOnExit=1 at .ini ,

It works, we have different Sessions with different options available and these are consistent with the Options menus info.
Note that by default this is also possible, for example ASCII in one window and Binary in the other but the Options Preferences Transfer menu shows only the value for last one selected .

But this new behaviour (not by default) has his own problems as the last window closed becomes master of preferences for new sessions.

Then I suggest the folowing:

A check Box (unmarked by default) near the OK button at Preferences (maybe also at Skip List) with the following text: 'Make Default' and driving the program to save or not to save at .ini file. (And forget the SaveOnExit variable)

BuGGy Desings can be adressed the Patchy way

----------
Should these comments qualify myself for the Suggestion of the Week's prize of a free registration code
----------

[bigstar]

Well the main idea behind the option design is so that the settings are passive, when you change options in one instance of FlashFXP opening the preferences in another seperate instance would now show those changed value. Call it what you want but this is how it was designed to work.

With your suggestion there is no way for the options to be passive. Changes made within one instance will not be updated in any other open instance and a restart would be required.

With most settings this passive design works well. However I agree there are some cases where this causes some adverse effects.

I'm not saying your way is right or wrong, better or worse. We just see things in two different ways.

[secamela]

Sorry but I still miss the advantages of the 'passive' policy for settings (sauf for the busy programmer).

"(...) when you change options in one instance of FlashFXP opening the preferences in another seperate instance would now show those changed value. "
...aaand tells you wrong things about the options of this other instance who now tells you I'm transfer ascii when it is transfer binary. May I say this sounds buggy. (even if it's this way by design)


"Changes made within one instance will not be updated in any other open instance and a restart would be required. "
...Changes in one instance are pertinent to that instance and maybe (if marked as default) for all new instances via the .ini file.

I'll say passive options are passive enough

Nevertheless my aim is to passivate my posts from now, thank you for your passive audience / patience!

----------
Should these comments qualify myself for the Suggestion of the Week's prize of a free registration code ?
----------