A little problem with v7.90.0300...

[admin]

The latest changes in data storage brought an important change I have not talked about yet in the change log:

Before, when you had different INI files in the same <xydata> path, then each INI file had its own independent history and tabs data. I, for example, regularly load Screenshot.ini for my XY screenshots: it starts XY with a certain perfect Window size and a number of tabs that are useful for a good screenshot.
Now, when I load Screenshot.ini and later exit, then the history and tabs data of Screenshot.ini overwrite the history and tabs data of XYplorer.ini in folder <xydata>\Panes\1! Not good.
So, in short: Something is shared now that was not shared before. And whenever you read an INI file from before v7.90.0300 then its data will overwrite any data in <xydata>\Panes\1.

What now?

One solution would be to do nothing but see the sharing of these data as a plus! After all, also Catalog, FVS, etc. are shared among all configs inside the same <xydata>. But then, of course, it would be consequent to also share a number of other data that are currently stored inside the INI file(s): Favorites, POM, VF, HiliteColors etc. ... probably in another DAT file called user.dat or so. Then the INI file(s) would just (more or less) hold the settings you do in the Configuration dialog, whereas user.dat would hold all "critical" data, i.e. mostly path and file names that you would not like to share with every person. Looks like a good separation of data to me.

Concerning my Screenshot.ini case, I would have to call XYplorer with a switch \ini=screenshot\ to force a different <xydata> folder to have my separate history and tabs data -- not ideal... another (or additional) solution would be to add an option "Share History and Tabs" (or inverse: "Private History and Tabs"), and if non-shared, then store the data in other subfolders of Panes\, namely in my case <xydata>\Panes\Screenshot_1\ and <xydata>\Panes\Screenshot_2\.

Any comments?

[Gandolf]

Just to show I still have an interest in XY, even though I don't use it anymore, I'll give my opinion.

I would expect the ini file to contain left (pane 1) and right (pane 2) sections. These should contain the tab specific information: path, filter, view mode etc... Everything that is related to each tab. I'm not sure how history by per tab would work in this case, I assume it would be saved for each pane so may have to be done differently to the present mode.

I can't see why everything else (address bar, toolbar, navigation panel etc...) can't be very much as it is in a "main frame" section covering everything that is common to both panes. I'm assuming, at the moment, a single tree and info panel.

I see the ini file as a snapshot of XY for a particular configuration and as such I would expect it to restore XY exactly as it was when I last used that configuration. The only exception is if the paths are no longer available, but that is already handled.

I don't know how practical it would be to provide a small conversion utility to update old ini files to a different format. I personally would be happy to load the 100+ configuration files into XY and then save them, assuming they could be read form the old format and written into the new format.

[admin]

Gandolf!!!

Now that's a surprise! You took quite a break.

The additional problem here are the tab*.dat files that have been stored in folder FindTemplates in previous versions. These files store Find settings per tab. There's no (good) way to incorporate them within the INI but they tightly interrelate with the history and tab data. To avoid making a big mess by stuffing everything into FindTemplates I decided to create the new Panes folder with subfolders.

In the next version I changed (developer's future-past-tense!) something along the lines I talked about in the first post of this thread. I think it handles everything fine now. Your 100+ INI-files should be migrated alright to the new data layout (make a backup anyway! ).

Don

[j_c_hallgren]

Just to show I still have an interest in XY, even though I don't use it anymore, I'll give my opinion.

As Don said, you took a looooong break from the forum! And thus, my question is: Is XY still doing something that you just can't stand so that's why you don't use it, or has it morphed enough so that you might return as user, even if occasionally?

BTW, it is nice to see that you still take an interest in XY!

[Gandolf]

... In the next version I changed (developer's future-past-tense!) something along the lines I talked about in the first post of this thread. I think it handles everything fine now...

Yes, that appears to work. However, it has shown up something I wasn't aware of. I have a lot of dat files left that belong to ini files that have been deleted. When a session had finished and I no longer needed the configuration, I simply deleted the ini file. Obviously, it doesn't delete the dat file so there are several hundred of them that don't belong to ini files!!!

Any ideas??

The one that comes to mind immediately is to have a configuration setting to delete a configuration, giving an option to select one in the same way as the load configuration does. It could then delete the dat file (and any other related files) as well as the ini file. I assume the currently loaded configuration file (and it's dat file) would be locked so it can't be deleted.

I've deleted a couple of orphaned dat files and everything seems O.K., or am I going to run into problems?

... Is XY still doing something that you just can't stand so that's why you don't use it...

It just doesn't "feel" right is the best way to describe it. Simple case: I want to view a file and extract some text. In x² or T.C. I open a viewing pane, select the text and copy it, close the viewing pane - done. In XY Ctrl+Q, then move focus to the info pane, then select the text - with the RAT!!! (keyboard doesn't work). I don't want to open the file in a text editor because there is the danger that the file could be modified, which I don't want.

There are just a lot of similar situation that irritate me because they don't work the way I like. The change in the drop down lists to wrap round drives me crazy!!

[serendipity]

In XY Ctrl+Q, then move focus to the info pane, then select the text - with the RAT!!! (keyboard doesn't work). I don't want to open the file in a text editor because there is the danger that the file could be modified, which I don't want.

Hi from me too! Meanwhile now XY has quick file view (F11), quite handy if you ask me.

[j_c_hallgren]

Simple case: I want to view a file and extract some text. In x² or T.C. I open a viewing pane, select the text and copy it, close the viewing pane - done. In XY Ctrl+Q, then move focus to the info pane, then select the text - with the RAT!!! (keyboard doesn't work).

Well, in order to do that, I use F11 (Quick File View/Full Screen Preview) which allows me to select text via keyboard or mouse, and then ESC to close it...have you tried that way? At least for this task? ok, so it only works for smaller files of non-text...but...maybe an idea.

[Gandolf]

True, I'd forgotten about quick file view. However, it can't view the end of large files - I'm often looking at very large log files and need to see the most recent information. Also (which I think has been mentioned) the window size can't be changed to display long lines without word-wrap. It's these sort of little things that gives the minus features that outweigh the plusses.

[admin]

... In the next version I changed (developer's future-past-tense!) something along the lines I talked about in the first post of this thread. I think it handles everything fine now...

Yes, that appears to work. However, it has shown up something I wasn't aware of. I have a lot of dat files left that belong to ini files that have been deleted. When a session had finished and I no longer needed the configuration, I simply deleted the ini file. Obviously, it doesn't delete the dat file so there are several hundred of them that don't belong to ini files!!!

Any ideas??

The one that comes to mind immediately is to have a configuration setting to delete a configuration, giving an option to select one in the same way as the load configuration does. It could then delete the dat file (and any other related files) as well as the ini file. I assume the currently loaded configuration file (and it's dat file) would be locked so it can't be deleted.

I've deleted a couple of orphaned dat files and everything seems O.K., or am I going to run into problems?

No problems. They are indeed orphaned and are never used. Even if they are not orphaned you could delete them without crashing the app: They just store the Find settings for Finding Tabs. If such a file is not found (which can only happen if another process deletes them) then the Finding Tab in question will do its search based on the current settings on Info Panel / Find Files, that's all.

Indeed I never programmed something to remove a configuration. Maybe later...

[Gandolf]

No problems. They are indeed orphaned and are never used. Even if they are not orphaned you could delete them without crashing the app...

Thanks Don, I'll clear them out.

Indeed I never programmed something to remove a configuration. Maybe later...

Just a thought for later, it'll keep things tidy for awkward people like me who delete ini files!

[admin]

Back to one idea of my first post:

Catalog, FVS, UDC, KS, etc. are shared among all configs inside the same <xydata>. Wouldn't it be just consequent to also share a number of other data that are currently stored separately inside the INI file(s): Favorites, POM, VF, HiliteColors etc. ... probably in another DAT file called user.dat or common.dat or so?

Well, it probably depends on your work style. The question is: Why do you use different INI files? (if you do at all) Which are data that you'd rather share between your INIs, and which would you rather have separate per-ini?

[Gandolf]

As I said previously, I expect an ini file to open XY in the same state as when I closed that ini file. The important information is the layout; tabs, columns and sort order, view mode and the filters applied to those tabs. That is what I would expect to be unique to a particular ini. I think that is how you intend to do it.

I do have some old ini files that appear to have different colour schemes, but I haven't bothered to change them. I would be quite happy for them to all have the same colour scheme.

The VF history I don't think would bother me too much if it was not restored as I'd left it 6 months ago. Same with the history. However, we come up against the history per tab situation (which I don't use) but that, by definition, should follow the tabs and therefore be unique to each ini file.

Favourites, probably expect them to be common, but not really bothered since I don't use them. Highlight colours I would assume would be common otherwise it could be confusing what the colours signify.

[avsfan]

As I said previously, I expect an ini file to open XY in the same state as when I closed that ini file. The important information is the layout; tabs, columns and sort order, view mode and the filters applied to those tabs. That is what I would expect to be unique to a particular ini. I think that is how you intend to do it.

I do have some old ini files that appear to have different colour schemes, but I haven't bothered to change them. I would be quite happy for them to all have the same colour scheme.

The VF history I don't think would bother me too much if it was not restored as I'd left it 6 months ago. Same with the history. However, we come up against the history per tab situation (which I don't use) but that, by definition, should follow the tabs and therefore be unique to each ini file.

Favourites, probably expect them to be common, but not really bothered since I don't use them. Highlight colours I would assume would be common otherwise it could be confusing what the colours signify.

I'd echo these ideas -- I use different INI files pretty much exclusively for tab settings. Everything else (I think) I'd like to have common between the windows (though perhaps different catalogs, but that's easily changeable now as well...)

Other things may come to mind, but for now the only reason I can think of that I use different INIs is for tab settings (along with each tab's history (as Gandolf mentioned), etc)...

[admin]

Hmm, other idea: IF tab settings is the exclusive reason for using different INI files, then it would make sense to add a new command switch to select the pane data (= tabs, history, and -- later -- tab caches) directory. Then one could have just one INI file (XYplorer.ini).

Code: Select all

XYplorer.exe /panes=screenshot

... would load the tabs etc. from <xydata>\Panes\Screenshot_1(2).

Maybe the MiniTree should also belong to that "history"-sort of data? Well, let's wait and see whether we get a Dual Tree...

[Gandolf]

Yes, for me certainly, the only major difference in the ini files is the tabs and their contents. I do have different window sizes but that can easily be handled. I use an AHK script to set various window sizes / positions as it is.

A couple of points:

1) Both panes would be saved together, even if only one was displayed. I often work with a single pane because of the long paths I use and, switch between them.

2) I don't know how you intend to save the tree data, for those who use the tree. I assume it would need to be associated with the panes but perhaps it would just update the tree if opened.

So, settings would loose all the configuration items and, added to the list catalogue, U.D.C's, etc... would be a save / load pane settings? Looks O.K. to me.

Judging by the response to this thread it appears that perhaps not many people use the ini files, but avsfan and I seem to agree in their use.