How about ViceVersa integration?

[jacky]

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

hmm.. ok, so this Custom Report thing, that would be an enhancement of the current report feature, or am I completely missing the point here ?

Because it seems to me that this sounds like an extended version of the idea of having templates that could be used for Reports (which I'd love, to generate HTML reports for example), given that it would be possible to trigger it using CKS; and if so, here are a few ideas I'd like not to be forgotten

[TheQwerty]

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...

Actually it was a bit more complex than it needed to be.

Assuming custom reporting can be handled via UDC we could have.
UDC generates custom report in the form of a .reg file.
UDC to open the .reg file (imports into the registry).
UDC to open VV.

Then with scripting the UDCs could be combined.

Now the problem of selecting all the files before generating the custom report. Drop Stacks, appending to the clipboard, or a multiple location search would all work here in my opinion.

And problem two is getting XY to wait between opening the reg file and executing VV so that the registry update can be completed. This could be fixed using script stepping, or a new script prompt or sleep function.

[TheQwerty]

hmm.. ok, so this Custom Report thing, that would be an enhancement of the current report feature, or am I completely missing the point here ?

Because it seems to me that this sounds like an extended version of the idea of having templates that could be used for Reports (which I'd love, to generate HTML reports for example), given that it would be possible to trigger it using CKS; and if so, here are a few ideas I'd like not to be forgotten

Yep, at least that's how I'm imagining it. And I think that thread might have been the reason I thought this was on the road map in the first place.

[j_c_hallgren]

Now the problem of selecting all the files before generating the custom report. Drop Stacks, appending to the clipboard, or a multiple location search would all work here in my opinion.

And problem two is getting XY to wait between opening the reg file and executing VV so that the registry update can be completed. This could be fixed using script stepping, or a new script prompt or sleep function.

For selecting the 2nd file, all I'd likely need would be a way to get the standard "Browse for Folder" (or whatever that thing is) pop-up to occur...not maybe best, but workable...could work for both files if none selected at begin of script.

As far as waiting, I thought the script wouldn't go to next CID unless prior cmd was done, so that results could be checked via #TEST (or similar)...yes, some sort of pause might be needed, but if exec is held up till a cmd finishes, just like if we were doing it manually, what's the issue?

[admin]

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.)

But that's not very intuitive, and can get quite lengthy when talking about different drives or even network...

JC's idea is not bad though! Select the items while the script is running... I had planned a <getfile>/<getfolder> variable (opening standard windows open file/select folder dialog) anyway, I just was waiting for a good use for it. Now here it is!

Another, and faster way (because those Windows dialogs are clumsy), would be to use a Catalog Category as an ad-hoc dropstack and collect all the material needed there. Also would be re-usable between sessions. And very easy to change order of items. Items could be referenced e.g. as <catalog 1> <catalog 2> etc. meaning "item 1 (2, 3...) in the current catalog category".

[TheQwerty]

For selecting the 2nd file, all I'd likely need would be a way to get the standard "Browse for Folder" (or whatever that thing is) pop-up to occur...not maybe best, but workable...could work for both files if none selected at begin of script.

I'd think it would be better to execute it after the files are selected, but that's me.

As far as waiting, I thought the script wouldn't go to next CID unless prior cmd was done, so that results could be checked via #TEST (or similar)...yes, some sort of pause might be needed, but if exec is held up till a cmd finishes, just like if we were doing it manually, what's the issue?

It might be that way, but I have a feeling on Open commands it doesn't wait for the program to finish. Just launches the program or file and continues on with the script. Remember this part will be happening outside of XY.

[j_c_hallgren]

JC's idea is not bad though! Select the items while the script is running... I had planned a <getfile>/<getfolder> variable (opening standard windows open file/select folder dialog) anyway, I just was waiting for a good use for it. Now here it is!

Thanks! Your proposal seems workable...but I'm still wondering if that Select shouldn't be available via a CID so user can pick desired folder without having to use the model file?

Another, and faster way (because those Windows dialogs are clumsy), would be to use a Catalog Category as an ad-hoc dropstack and collect all the material needed there. Also would be re-usable between sessions. And very easy to change order of items. Items could be referenced e.g. as <catalog 1> <catalog 2> etc. meaning "item 1 (2, 3...) in the current catalog category".

YEA! That would be a very good solution also...but I think the on-the-fly primitive select needs to be an option also.

Addendum:

It might be that way, but I have a feeling on Open commands it doesn't wait for the program to finish. Just launches the program or file and continues on with the script. Remember this part will be happening outside of XY.

Ok, but the Open to execute a pgm will likely be the last item done in script, right? So this may not be an issue...

Addendum #2: FYI: We're discussing a Stop/Pause (sleep) command in this other thread: http://www.xyplorer.com/xyfc/viewtopic.php?t=2109

[TheQwerty]

It might be that way, but I have a feeling on Open commands it doesn't wait for the program to finish. Just launches the program or file and continues on with the script. Remember this part will be happening outside of XY.

Ok, but the Open to execute a pgm will likely be the last item done in script, right? So this may not be an issue...

Yes and no. I'm actually talking about two opens. The first applies the changes to the registry by executing the .reg file. This will require the user answer a dialog to allow the changes (this is not an XY dialog but the standard system one that appears if you double click a reg file in Windows Explorer). The second would actually run VV. If XY doesn't pause between, the user may not answer the .reg file dialog before VV is run and thus the changes wouldn't have been made yet.

That's one advantage of going the more complicated way I had first suggested in that you'll have more control over all of this. Not that Don couldn't give us more, but I'm not sure how far he wants to take scripting.

[j_c_hallgren]

Yes and no. I'm actually talking about two opens. The first applies the changes to the registries by executing the .reg file. This will require the user answer a dialog to allow the changes. The second would actually run VV. If XY doesn't pause between, the user may not answer the .reg file dialog before VV is run and thus the changes wouldn't have been made yet.

OH! Ok...now I follow your thinking, which differs from mine, thus the confusion...my theory was not to use a .REG file that would need to be merged externally, but rather have a special command available that would update Registry within XY...yes, that does somewhat violate the rule that XT doesn't touch Registry, but this would be strictly based on user request with user defined data so it's not automatic or hidden as most all other apps do when they muck around in Registry.

Addendum: As stated in another thread, I think (hope?) we've helped XY make some good progress via these discussions today, as having input from many folks can sometimes lead to unrealized problems and solutions to same.

[KyferEz]

those Windows dialogs are clumsy

Completely agreed!

Addendum: As stated in another thread, I think (hope?) we've helped XY make some good progress via these discussions today, as having input from many folks can sometimes lead to unrealized problems and solutions to same.

Agreed. And I for one am anxious to see the results!

KyferEz

[admin]

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

hmm.. ok, so this Custom Report thing, that would be an enhancement of the current report feature, or am I completely missing the point here ?

Because it seems to me that this sounds like an extended version of the idea of having templates that could be used for Reports (which I'd love, to generate HTML reports for example), given that it would be possible to trigger it using CKS; and if so, here are a few ideas I'd like not to be forgotten

Ah, thanks for digging this up!

Some things need time to ripen... (as I already mentioned here: http://www.xyplorer.com/xyfc/viewtopic.php?p=2669#2669). Now, with UDC, the interface for Custom Reports is there... the puzzle pieces can be put together...

[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!!!

Uhm, sorry, I might have confused you here... I did mean to say "UDC New", not New Items (menu)! I was thinking about using the Source as template for reports.

Now, a day later, rather than adding a checkbox I'd add a whole new UDC category: Report! What can you do with these Report UDCs? For example:
- HTML reports of file listings
- Property sheets of particular files
- snapshots of the current windows system properties
- hell, you could shoot any text bits up to the clipboard*, and paste them into the editing you are just doing...

Whatever! It all depends on the array of variables that are provided, and this can grow with time...

* Optionally, the text is shot up to the clipboard!

[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!

Just FYI: forget about the limit! This was before the idea came up to use template files...