How about ViceVersa integration?

[admin]

Isn't some sort of custom reporting on your road map, Don? I don't see it on the one in the forum, but perhaps on one of those lists floating around your desk? (If not I'll post a formal wish with a bunch of details I have in mind.)

Not necessary! I have tons of great ideas for custom reporting, but this book will not be opened before some other things are closed.

[serendipity]

My only concern is like TheQwerty said, avoid registry since portability highly depends on this. As I understand the only registry value XY has now is shell integration and the user is warned before registry is written.
Also, I would not like to see any context or other menus belonging to VV in XY. If I dont use VV, menus will be greyed i guess, but that is not good to see especially for newbies. I assume you plan just a UDC kind of thing for VV integration.
Good thing about this is, dual paners will be happy about it and it will save you a lot of trouble handling future dual pane wishes.
But again, if VV is integrated just as an option and its non-users wont notice a thing then I am all for it.

PS: does this mean you are willing to integrate (via UDC or other means) any other free product useful to XY community
Does this also mean you will become lazy to write your own codes and just integrate other products? . Just kidding.

[admin]

My only concern is like TheQwerty said, avoid registry since portability highly depends on this. As I understand the only registry value XY has now is shell integration and the user is warned before registry is written.
Also, I would not like to see any context or other menus belonging to VV in XY. If I dont use VV, menus will be greyed i guess, but that is not good to see especially for newbies. I assume you plan just a UDC kind of thing for VV integration.
Good thing about this is, dual paners will be happy about it and it will save you a lot of trouble handling future dual pane wishes.
But again, if VV is integrated just as an option and its non-users wont notice a thing then I am all for it.

PS: does this mean you are willing to integrate (via UDC or other means) any other free product useful to XY community
Does this also mean you will become lazy to write your own codes and just integrate other products? . Just kidding.

Some UDC integration in a general way would be okay for me. Since VV apparently depends on a kind of INI file for its job, that inspires me to a new type of UDC: Write a text file! You could define Name and Contents of the file, and the contents of course could be defined with all sorts of variables... before you freak out: there will be limit of 32K data per file for this kind of operation!

[TheQwerty]

Not necessary! I have tons of great ideas for custom reporting, but this book will not be opened before some other things are closed.

That's completely understandable (and appreciated). There's a number of features that I'm more excited about anyhow.

Besides, and perhaps I take this for granted, Open With is powerful enough that some custom apps could be written to generate beautiful reports externally.

[admin]

Not necessary! I have tons of great ideas for custom reporting, but this book will not be opened before some other things are closed.

That's completely understandable (and appreciated). There's a number of features that I'm more excited about anyhow.

Besides, and perhaps I take this for granted, Open With is powerful enough that some custom apps could be written to generate beautiful reports externally.

Nice idea! I might even do it myself... .... keeps the main exe smaller...

[TheQwerty]

Some UDC integration in a general way would be okay for me. Since VV apparently depends on a kind of INI file for its job, that inspires me to a new type of UDC: Write a text file! You could define Name and Contents of the file, and the contents of course could be defined with all sorts of variables... before you freak out: there will be limit of 32K data per file for this kind of operation!

How about something like the custom New Items? We could have templates with special variables and all XY does is give those variables meaning.

EDIT: Essentially, what I was thinking for custom reporting as well.

[admin]

Some UDC integration in a general way would be okay for me. Since VV apparently depends on a kind of INI file for its job, that inspires me to a new type of UDC: Write a text file! You could define Name and Contents of the file, and the contents of course could be defined with all sorts of variables... before you freak out: there will be limit of 32K data per file for this kind of operation!

How about something like the custom New Items? We could have templates with special variables and all XY does is give those variables meaning.

That's a great idea!!!! It would be just another checkbox in New Items like "Process contents" or so... man!!!

[j_c_hallgren]

And then to make this work for VV, one would need a UDC that would input this file and update the specified keys in the Registry...if it was properly fomatted, one could thus also delete keys/values via use of the null or hypen.

Now about this text file creation...in my first reply to this thread (post 3), I wrote this:

BTW, I do see the value of adding some generic abilities needed to possibly interface to other products via creation of temporary INI or similar files! The ability to locate desired folders via XY and then using those paths to build either command lines or a simple text type file (Maybe using some model file as basis? Maybe in XML?) that the other appl can use might then be usable by other app's than just VV.

Isn't that what we are now talking about?

[TheQwerty]

How about something like the custom New Items? We could have templates with special variables and all XY does is give those variables meaning.

That's a great idea!!!! It would be just another checkbox in New Items like "Process contents" or so... man!!!

The only thing that has concerned me with this thought is how to do something for each item passed. It's not as simple as just going in and replacing <items> with the list of selected files, I'm afraid.

We might just need to define a syntax to be used for these files (for example):
<header>stuff to do before the first item</header>
<body>stuff to do for each item</body>
<footer>stuff to do after last item</footer>

And then have special variables that could be parsed in each <fileCount>, <totalSize>, <item>, <itemPath>, <itemDate-M>, <itemSize>, etc., etc..

Like so many things this has the potential to become quite complex.

Two decent examples that spring to mind are the foo_utils component's Text Tool feature for Foobar2000, or the export feature in Mp3tag.

I can give more details on either if wanted (when you're ready to tackle this), but I feel I've pulled this thread far enough off topic for that now.

[TheQwerty]

And then to make this work for VV, one would need a UDC that would input this file and update the specified keys in the Registry...if it was properly fomatted, one could thus also delete keys/values via use of the null or hypen.

Now about this text file creation...in my first reply to this thread (post 3), I wrote this:

BTW, I do see the value of adding some generic abilities needed to possibly interface to other products via creation of temporary INI or similar files! The ability to locate desired folders via XY and then using those paths to build either command lines or a simple text type file (Maybe using some model file as basis? Maybe in XML?) that the other appl can use might then be usable by other app's than just VV.

Isn't that what we are now talking about?

Yep that's where we've taken the thread.

The way I'd picture this could work with VV is as such:
Outside of XY:
You have a template that generates the .reg file to import the new keys.
You also have a batch file (or other launcher), which imports the .reg file and then executes VV. (It could even back up the settings before importing and restore them when VV is closed.)

Inside of XY:
You will have a UDC to generate the report (.reg file) and one to Open the batch file.
With scripting the two UDCs could be combined into a single UDC or Catalog item.

So all you'd have to do is select the two folders and execute the script.
XY would generate the .reg file and then execute the launcher.
The launcher would take control now and import the reg values and then run VV.

[admin]

How about something like the custom New Items? We could have templates with special variables and all XY does is give those variables meaning.

That's a great idea!!!! It would be just another checkbox in New Items like "Process contents" or so... man!!!

The only thing that has concerned me with this thought is how to do something for each item passed. It's not as simple as just going in and replacing <items> with the list of selected files, I'm afraid.

We might just need to define a syntax to be used for these files (for example):
<header>stuff to do before the first item</header>
<body>stuff to do for each item</body>
<footer>stuff to do after last item</footer>

...

Man, you are fast and you are reading my mind. It's almost frightening... I was cooking (and I'm still! Gotta hurry....) in the meantime and generated the same approach. Plus 2 more sections.
Comments: your stuff for yourself (not outputted)
Rules: anything general for XY, like line width, certain characters to be used etc...
header: ...
body: ...
footer: ...

So, out of the blue Custom Reports are suddenly standing right in the middle of the room! (Plus, VV and whatever integration.)

[admin]

And then to make this work for VV, one would need a UDC that would input this file and update the specified keys in the Registry...if it was properly fomatted, one could thus also delete keys/values via use of the null or hypen.

Now about this text file creation...in my first reply to this thread (post 3), I wrote this:

BTW, I do see the value of adding some generic abilities needed to possibly interface to other products via creation of temporary INI or similar files! The ability to locate desired folders via XY and then using those paths to build either command lines or a simple text type file (Maybe using some model file as basis? Maybe in XML?) that the other appl can use might then be usable by other app's than just VV.

Isn't that what we are now talking about?

Yeah, but you did not mention the term "New Items"!

[admin]

And then to make this work for VV, one would need a UDC that would input this file and update the specified keys in the Registry...if it was properly fomatted, one could thus also delete keys/values via use of the null or hypen.

Now about this text file creation...in my first reply to this thread (post 3), I wrote this:

BTW, I do see the value of adding some generic abilities needed to possibly interface to other products via creation of temporary INI or similar files! The ability to locate desired folders via XY and then using those paths to build either command lines or a simple text type file (Maybe using some model file as basis? Maybe in XML?) that the other appl can use might then be usable by other app's than just VV.

Isn't that what we are now talking about?

Yep that's where we've taken the thread.

The way I'd picture this could work with VV is as such:
Outside of XY:
You have a template that generates the .reg file to import the new keys.
You also have a batch file (or other launcher), which imports the .reg file and then executes VV. (It could even back up the settings before importing and restore them when VV is closed.)

Inside of XY:
You will have a UDC to generate the report (.reg file) and one to Open the batch file.
With scripting the two UDCs could be combined into a single UDC or Catalog item.

So all you'd have to do is select the two folders and execute the script.
XY would generate the .reg file and then execute the launcher.
The launcher would take control now and import the reg values and then run VV.

Yep, a bit complex maybe, but once it is set up, itz's just a click. The only thing still missing is how to select 2 files in different locations. It might be time for drop stacks, or at at least for a Copy-Append to clipboard (and then get the files from clipboard).

[j_c_hallgren]

Yep, a bit complex maybe, but once it is set up, itz's just a click. The only thing still missing is how to select 2 files in different locations. It might be time for drop stacks, or at at least for a Copy-Append to clipboard (and then get the files from clipboard).

I see the problem slightly differently...as the user would need ability to select (if needed) the desired files/paths while script is running, instead of them being pre-defined, and I'm just not familiar with it thus far to know if that's possible.

Also, theQuerty's flow as described seemed a bit complex to me...I was thinking (as stated) something along lines where the clipboard data could be used as input to a special UDC that would update Registry with that value for a specified key...ok, so in this case, there are two keys, so that would cause two UDC's...hummm...

[TheQwerty]

Yep, a bit complex maybe, but once it is set up, itz's just a click. The only thing still missing is how to select 2 files in different locations. It might be time for drop stacks, or at at least for a Copy-Append to clipboard (and then get the files from clipboard).

That's really the only problem I anticipate as well. But my thoughts were the user could do a multiple location search to have them both/all available in the list pane. (It's not ideal but it works until something better is in place.)