Multi-combo of script(s) and UDC(s)

[TheQwerty]

Nicely done Don - that's much better!

Will we be seeing tree/list values coming to other commands as well?

[ivan]

Would it please be possible to recreate a script to incorporate the new changes that have been made? Thank you

[ivan]

So how can we rework this script

Code: Select all

Set(%cf%,<curfolder>);
   Set(%cp%,<curpath>);
   Set(%nn%,<date yyyymmddhhnnss>);
   OpenWith("""C:\program files\winrar\winrar.exe"" e -- *.rar * %nn%-temp\", "s");
   Msg("Press OK when WinRAR is finished.",1);
   GoTo("<curpath_s>\%nn%-temp")
   Sel(a);
   Rename(bat,%cf%);
   Focus(L);
   MoveTo("..\..");
   #523;
   #523;
   Rename(bat,%nn%,,"%cp%");
   SelFilter(%nn%, d, Name);
   Focus(L);
   #169;

to comply with the latest changes that have made?

EDIT: My bad, I thought the changes in the beta would have messed up with the delete function but they didn't and everything still works as it should

[ivan]

THIS IS A CRUCIAL QUESTION!

Can scripting currently check if a certain process is running? I think it's possible to implement because a quick bit of Googling found this info:

EnumWindows

The EnumWindows function enumerates all top-level windows on the screen by passing the handle of each window, in turn, to an application-defined callback function. EnumWindows continues until the last top-level window is enumerated or the callback function returns FALSE.
VB4-32,5,6
Declare Function EnumWindows Lib "user32.dll" (ByVal lpEnumFunc As Long, ByVal lParam As Long) As Long

Operating Systems Supported
Requires Windows NT 3.1 or later; Requires Windows 95 or later

Library
User32

Parameter Information
· lpEnumFunc
Points to an application-defined callback function. For more information, see the EnumWindowsProc callback function.

· lParam
Specifies a 32-bit, application-defined value to be passed to the callback function.

Return Values
If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

After implementing above, we can specify the name of the window and match it with the one of a running process.

[jacky]

hmmm, yes, "crucial".....

[ivan]

hmmm, yes, "crucial".....

Was that sarcastic? If yes then it wasn't necessary. It's important to know if check for a specific running (and not running) process can be performed, especially when external applications are being utilised to do work via a script. Being able to determine the above would help automate some scripts even more, which would make them more efficient and isn't efficiency the whole point of XYplorer?!

[TheQwerty]

hmmm, yes, "crucial".....

Was that sarcastic? If yes then it wasn't necessary. It's important to know if check for a specific running (and not running) process can be performed, especially when external applications are being utilised to do work via a script. Being able to determine the above would help automate some scripts even more, which would make them more efficient and isn't efficiency the whole point of XYplorer?!

"You keep using that word. I do not think it means what you think it means."

First, no it's not currently possible within XY.
Second, you wouldn't want to use EnumWindows. That tells you nothing about the processes running.
Third, this would be trivial to incorporate into XY with AutoHotkey or any other scripting language.

[ivan]

"You keep using that word. I do not think it means what you think it means."

Yes, I do know what it means. The problem that I see is that when conceiving, how can anyone overlook the fact that there is a huge probability that external apps would be used to carry out the task and as such it should be possible to know once it's done.

First, no it's not currently possible within XY. Second, you wouldn't want to use EnumWindows. That tells you nothing about the processes running. Third, this would be trivial to incorporate into XY with AutoHotkey or any other scripting language.

EnumWindows would get the text of a window and if matched to set value then bingo! And if it's trivial then how do you propose process monitoring should be incorporated into XY?

[TheQwerty]

"You keep using that word. I do not think it means what you think it means."

Yes, I do know what it means. The problem that I see is that when conceiving, how can anyone overlook the fact that there is a huge probability that external apps would be used to carry out the task and as such it should be possible to know once it's done.

A simple Msg box after that the user clicks to say "Hey the program finished successfully!" solves this issue. Thus, it's not crucial. Would it be beneficial if XY scripting had a Run & Wait command, yes. But it is not crucial!

EnumWindows would get the text of a window and if matched to set value then bingo!

Yes, it gets information about Windows - not processes! What if the executed program doesn't create a window? EnumWindows would be useless here.

And if it's trivial then how do you propose process monitoring should be incorporated into XY?

Incorporated into XY was a bad choice of words on my behalf. What I meant is it would be trivial to use an external script or program to get around this "crucial" show-stopping bug. For example...

In the XY script:
Do whatever you do before running the program.
Call an AHK script to execute the actual program (instead of calling the program directly).
Display a message box before completing the script.

In the AHK script:
Execute the program.
Wait for the program to finish.
Close the message box automatically.

That gets around the limitation and removes the difficulty of having the user click the message box to continue.

[ivan]

A simple Msg box after that the user clicks to say "Hey the program finished successfully!" solves this issue. Thus, it's not crucial. Would it be beneficial if XY scripting had a Run & Wait command, yes. But it is not crucial!

In my case it adds no efficiency and hardly makes it more automated. Having not been around when scripting was first thought of, I'm struggling to understand what the concepts were. Was it first founded as a one-internal-operation kind of thing? Seems that way because making it so you can access and utilise external apps and combining scripting commands into one chunk of XYS code HAS to require the monitoring of what's going on. As of right now, displaying Msg box in which the user can confirm seems to me as an apple falling close to the tree of stepping through a script with no prompt for confirmation.

Yes, it gets information about Windows - not processes! What if the executed program doesn't create a window? EnumWindows would be useless here.

In my case it does create a window (and a process) so it wouldn't be useless

Incorporated into XY was a bad choice of words on my behalf. What I meant is it would be trivial to use an external script or program to get around this "crucial" show-stopping bug. For example...

In the XY script:
Do whatever you do before running the program.
Call an AHK script to execute the actual program (instead of calling the program directly).
Display a message box before completing the script.

In the AHK script:
Execute the program.
Wait for the program to finish.
Close the message box automatically.

That gets around the limitation and removes the difficulty of having the user click the message box to continue.

I'm confused. You say that it's trivial to use an external script or program, but then you go ahead and use an external script that relies on an external utility. Surely that's offloading the workload onto an outside program instead of dealing with and improving things in-house.

[TheQwerty]

I'm confused. You say that it's trivial to use an external script or program, but then you go ahead and use an external script that relies on an external utility. Surely that's offloading the workload onto an outside program instead of dealing with and improving things in-house.

I never said Don shouldn't improve XY scripting, or that a Run & Wait function wouldn't be useful, just that it's trivial to write and use an external script/program called from XY to do the executing and closing of a message box.

Really, my only point is that just like holding the user's hand through the tough times when they attempt to empty an empty recycle bin, this isn't crucial.

[ivan]

I never said Don shouldn't improve XY scripting, or that a Run & Wait function wouldn't be useful, just that it's trivial to write and use an external script/program called from XY to do the executing and closing of a message box.

Really, my only point is that just like holding the user's hand through the tough times when they attempt to empty an empty recycle bin, this isn't crucial.

I'm not asking an external program to do the executing and closing of a message box, it should all be part of scripting.

Let's get something straight here. What's crucial and what isn't is a matter of opinion. Just because you don't think something is crucial doesn't render it unimportant. I personally don't think FVS is crucial and if catalogue wasn't a part of XY then I wouldn't loose a second of my sleep tonight. The point is that while something can be one man's crap, it can also be another man's gold. Horses for courses or whatever the expression you prefer to use. Some people are happy with XY in its current state, others would very much like to see it become more efficient and more automated, which was the whole point of scripting, correct? You'd be surprised how quickly everyday tasks become crucial to some people.

[j_c_hallgren]

What's crucial and what isn't is a matter of opinion. Just because you don't think something is crucial doesn't render it unimportant. I personally don't think FVS is crucial and if catalogue wasn't a part of XY then I wouldn't loose a second of my sleep tonight.

While I'll agree that crucial is a matter of opinion, I think that in the overall scheme of things FVS and the catalog are definitely crucial and that is based on 2 1/2+ yrs of history here...both features are of use to almost everyone who uses XY, while scripting is a niche feature that many users will never touch.

You'd be surprised how quickly everyday tasks become crucial to some people.

And that's part of why I personally, as above, highly depend on the catalog and now FVS! Scripting is just icing on the cake, but the catalog IS the cake! It's one feature which I believe is unique to XY and thus leads to new users/sales, who can use it immediately, even if they are limited in knowledge.

It appears that we disagree on this, which is fine, but think of the overall/entire user base to determine how valuable a new feature may be.

[ivan]

While I'll agree that crucial is a matter of opinion, I think that in the overall scheme of things FVS and the catalog are definitely crucial and that is based on 2 1/2+ yrs of history here...both features are of use to almost everyone who uses XY, while scripting is a niche feature that many users will never touch.

I think things that you don't come to expect when you migrate over to XY from WE can't be considered crucial, so that rules out the catalogue and a heap of other things. That's not to say that they aren't great though.

It would also be a good thing to set up a few polls to find out what features people use and how often. Personally, if there is no FVS then I wouldn't have shed a tear, so it's a nice-to-have feature.
Just because many users don't touch scripting should undermine those people that do. After all, look at jacky - prime example of how deep scripting can get.

And that's part of why I personally, as above, highly depend on the catalog and now FVS! Scripting is just icing on the cake, but the catalog IS the cake! It's one feature which I believe is unique to XY and thus leads to new users/sales, who can use it immediately, even if they are limited in knowledge.

It appears that we disagree on this, which is fine, but think of the overall/entire user base to determine how valuable a new feature may be.

I don't depend on the catalogue or FVS, but that's me and we're all different. For me scripting+UDC are the cake and FVS is the icing. Making something unique to XY doesn't necessarily lead to improvement is users/sales.

For someone who I remember saying (correct me if I'm wrong!) that it's the sheer amount of customization that can be done to XY to suit user's needs is the beauty of XYplorer, I'm surprised to read that you think that the majority should rule on the value of a potential new feature. Customization isn't for everyone as you very well know. Some people are happy with it out of the box and I salute them. Some people are after something special though. Do you know know a saying that goes "If you look after the pennies, the pounds will look after themselves"? I think it highlights rather well what I mean.

[j_c_hallgren]

For someone who I remember saying (correct me if I'm wrong!) that it's the sheer amount of customization that can be done to XY to suit user's needs is the beauty of XYplorer, I'm surprised to read that you think that the majority should rule on the value of a potential new feature.

Yes, I've said that...but that also doesn't discount that when a feature continues to keep getting asked for over time by new users, it makes business sense to work on those first and then add other lesser requested features as time allows...so I'm not saying that majority should rule on features, but they certainly can influence the importance of which ones are added and in what order.

I think things that you don't come to expect when you migrate over to XY from WE can't be considered crucial, so that rules out the catalogue and a heap of other things. That's not to say that they aren't great though.

Same can thus be said for scripting and UDC, right? Win Expl doesn't have these (unless they hid them really well!) but it does have a variant of FVS, so that is more expected.