[WDX] Autorun Plugin: Run commands/set envvars on TC start

[Fla$her]

With other tools I just refer to various apps and scripts that I uses regularly.)

In scripts, you can create an instance of a class with a namespace connection that calls the WMI Performance adapter service (wmiprvse.exe), which caches data in memory for fast queries by class.
Today we will discuss this point, but there are doubts that the system capabilities of scripts can be easily adapted to a third-party tool.

E.g. CPU/GPU name, etc...

You can already get the CPU name via GetCPUInfo('CPUBrandString').

>>> I was just wondering whether GetWMIValue can be sped up to improve the update rate (to let's say 1-2s or the like in my use case).

Well, I see the header update when executing my corrected code in about 1-1.3 seconds.

However, for other queries you might not know a value for filtering or even need the information from several rows. Then it is very helpful to iterate over the available rows.

The selection of elements in the returned array was discussed a long time ago. Reminded him.

[funkymonk]

In scripts, you can create an instance of a class with a namespace connection that calls the WMI Performance adapter service (wmiprvse.exe), which caches data in memory for fast queries by class.
Today we will discuss this point, but there are doubts that the system capabilities of scripts can be easily adapted to a third-party tool.

Thank you for discussing! Maybe there is a way to speed it up.

You can already get the CPU name via GetCPUInfo('CPUBrandString').

True. But this was just an example. There is obviously more in WMI that is interesting ...

However, for other queries you might not know a value for filtering or even need the information from several rows. Then it is very helpful to iterate over the available rows.

The selection of elements in the returned array was discussed a long time ago. Reminded him.

Great! Thank you again. That would be very helpful.

[Fla$her]

No problem.

But this was just an example.

In any case, the names are not dynamic data. For them, it's enough to create variables once at TC start.

Added: The author said that due to the low degree of usefulness of the indication itself and a certain complexity of implementation, the requested improvements for WMI are not prioritized.

[funkymonk]

Added: The author said that due to the low degree of usefulness of the indication itself and a certain complexity of implementation, the requested improvements for WMI are not prioritized.

Ok. I guess this relates to both (1) the iterator for the table and (2) the speedup, right?

Thanks for asking anyway!

[Fla$her]

Ok. I guess this relates to both (1) the iterator for the table and (2) the speedup, right?

To optimization in general. Connecting to a specific namespace is also important.

[funkymonk]

Hi there.

I have just encountered the following problem with Autorun 2.2.10 beta (for TC 10.52x32):

I have launched a periodic thread via "RunThread".
As long as this thread is running, cm_UnloadPlugins causes TC to terminate (without error message).

A quick solution is to *explicitly* use "Pragma AutorunBlockUnload" in the autorun configuration to prevent unloading the plugin.

Suggestion: Maybe Autorun should prevent unloading *implicitly* as long as at least one such thread is running.
Alternative: End the thread in a controlled way before letting TC unload the plugin.

[Fla$her]

2funkymonk
For me, the allocation to the thread makes sense only for functions with infinite loops, i.e. in this case, those that will be active in the current session until TC is closed. Therefore, I do not see the point in such a condition for unloading.
And I suspect that this is a problem with GetWMIValue in your function, and not with any other command being called. Am I right?

[funkymonk]

Yes, I do use GetWMIValue in my thread.
However, the problem doesn't seem to have anything to do with WMI.

Here is a small working example (without WMI):

Code: Select all

RunThread UpdateTCHeader2

Func UpdateTCHeader2
   i = 0
   While i < 5
      i = i + 1
      WinSetText("Test: " & i)
      Sleep(1000)
   Wend
EndFunc

As long as this thread (and *only* this one) runs, TC crashes when cm_UnloadPlugins is called.
Once the thread has terminated, cm_UnloadPlugins does no longer crash TC.

[Fla$her]

2funkymonk
Yes, I confirm. I'll ask if it can be fixed.

[beb]

<deleted>

Edit: looks like it's been my local issue with Total Commander .ini, at least I need some more time to check what's going on.

[Fla$her]

2beb
The text was deleted in vain. Some problems may already be known.

[dmocha]

Hi,
Do I understand correctly that the plugin can handle actions when closing the TC?
If so, what entry should I add to autorun.cfg so that when closing the TC the running exe file also closes?
In my case it's: %commander_path%\addon\TotalMouseEx\TotalMouseEX.exe
My guess is that this should be below the line: Pragma AutorunFinalizeSection

[Gral]

In general - if program doesn't support switch/parameters for close itself (as e.g. IrfanView do) just use

Code: Select all

TASKKILL /IM program.exe /T /F

[dmocha]

I tried but I get an error:
---------------------------
Autorun plugin error
---------------------------
Error in command at line [32]:
Unknown command: taskkill
---------------------------
OK
---------------------------

[Gral]

Try "taskkill.exe" or even full pathname "C:\Windows\System32\taskkill.exe"