Saját program vezérlése Script-ből
2021-09-08T14:47:02+02:00
2021-09-11T12:53:41+02:00
2022-08-12T04:30:29+02:00
FejGyuri
Milyen módokon lehet egy VBScript-ből vezérelni egy általam készített (VB) programocskát?
Eddig ezekre gondoltam:

1) A script a parancsokat egy txt file-ba menti, és a programocska időnként 'belenéz' a file-ba... (Nehézkes és lassú, mert a program nem azonnal értesül a parancsról, és a parancs kiolvasását sem lehet a végtelenségig sűríteni, a kiolvasáshoz szükséges idő miatt... Ezen kívül egy lassúbb gépen a kiolvasási idő is tovább tart...)

2) Ugyanez környezeti változóval... (Ugyanez a baja...)

3) 'WScript.GetObject'-tel, vagy valahogy másképp meg lehet oldani, hogy a script meg tudjon nyitni egy objektumot, és ezen keresztül el tudjak érni az -éppen futó- programban pl. egy eljárást? (Excellel ez megy...)
Valahogy fel kell / lehet készíteni a programomat arra, hogy a 'GetObject' hozzáférjen?
(A 'GetObject' kísérlet eddig nem sikerült. (A 'WshShell.exec' pedig nem erre való, az nem lát bele a programba...)
Mutasd a teljes hozzászólást!
Bocs, lehet, hogy elnagyoltan fogalmaztam...  (Nem biztos, hogy tökéletesen használom a szakszavakat...) Nyilván attól, hogy egy -üzeneti értékkel bíró kód -a küldő alkalmazás kezdeményezésére- bekerül egy környezeti változóba vagy egy fájlba, vagy akár a registry-be, ettől ez még csak egy halott információ... Mivel én nem ismerem a fogadó program objektuma(i)hoz-, így azok tulajdonságaihoz- vagy metódusainak indításához való hozzáférés lehetőségét, azt az elvet választottam (egyenlőre), hogy az irányító szkript elhelyez egy parancs-információt egy megbeszélt helyre (pl. környezeti változóba vagy fájlba), és a fogadó program -a tőle telhető leggyakrabban- megnézi, van-e csomagolva valamilyen 'üzenet' a számára. Ha talál ilyet, akkor azt -a közös szótár alapján- értelmezi, és ha tudja, végrehajtja, majd ugyanerre a helyre (környezeti változóba vagy fájlba) ő is becsomagolja a saját visszajelzését: pl. megtaláltam (az új) parancsot-, tudtam-, vagy nem tudtam értelmezni, teljesítettem vagy nem teljesítettem, stb.

Mivel az irányító szkript -a saját parancs-információjának a becsomagolása után várakozó ciklusba kezd, és ő is gyakorta nézegeti a megegyezett környezeti változót vagy fájlt, a kiolvasott visszajelzés értelmezésével el tudja dönteni, mit tegyen a továbbiakban...

Hát, én így gondoltam a parancs- és visszajelzés információk -adott- txt fájlba csomagolgatásának a 'technikáját'. Ennek a módszernek a révén a szkript és a program -a vártnál gyorsabban-, (átlagosan 20 ms alatt) tudnak üzenetet váltani egymással. Ez így nekem (egyenlőre) már tökéletes, de gondolva a jövőre, érdekelnek a haladóbb módszerek is...
Mutasd a teljes hozzászólást!

  • Talán a  Named Pipe nevű eszközt lehetne kipróbálni.
    Named pipe - Wikipedia
    Mutasd a teljes hozzászólást!
  • Eddig nem sok hozzászólás érkezett... Úgy látszik,  vagy nem gyakori-, vagy nem könnyű probléma...
    NevemTeve úrnak köszönöm  szépen az igyekezetét...
    Ha pedig valaki más is ide tévedne: Két napja gyűltek tanulságok bőven...

    1) A WScript.GetObject-tel (én úgy gondolom) csak erre felkészített-, éa regisztrált programmal (Még Notepad-dal sem) lehet kapcsolatot felvenni. Nekem az SK programocskámmal legalábbis nem sikerült...

    2) A környezeti változós módszer nem alkalmas gyors adatcserét megoldani, mert fagyogat az oprendszer (egy pár másodpercre), amikor összetalálkoznak a környezeti változókhoz való író-, és olvasó hozzáférések, és kézben tarthatatlanok az összeakadások. Bár először ez tűnt a kezelhetőbbnek, mégis kénytelen voltam lemondani erről a megközelítésről...

    3) Végül a a fájlba írós- és kiolvasós módszerrel sikerült megoldani a parancsokat küldő (script) és az azokat fogadó SK program kommunikációját! A 'protokoll' végiggondolása úgy negyedszerre sikerült (nekem ez abszolút ismeretlen terület): figyelni kellett, hogy a küldő- és a fogadó alkalmazások ne pont egyszerre akarják megnyitni a fájlt: a sikertelen  file-megnyitások után újra-próbálkozó ciklusokkal tudtam egész jól ezt megoldani. A parancs-feldolgozás sikerességének-, vagy sikertelenségének a visszajelzését is sikerült belevarázsolni, tehát a szkript megvárja, amíg a fogadó program visszaigazolja, mit tudott kezdeni az imént küldött paranccsal,  és addig nem kezd bele a következő parancs 'becsomagolásába'.

    Egy szó, mint száz, nem hiszem, hogy mágusoknak sok újdonságot mondhatnék, de azért szeretném megtisztelni azokat, akik először próbálkoznak ilyesmivel, és szivesen megosztom a részleteket azzal, akit érdekel...
    Mutasd a teljes hozzászólást!
  • Miért nem küldöd el üzenetként a vezérlő parancsot?
    Mutasd a teljes hozzászólást!
  • Megjegyzés: Környezeti változókat nem lehet két processz között küldözgetni, se gyorsan, se lassan. Talán registry-re vagy ini-fájlra gondolsz?
    Mutasd a teljes hozzászólást!
  • Szerintem a kérdés rossz. Nem azt kérdezzük hogy milyen módon lehet, hanem azt hogy mi az igény...

    Amit te keresel az az onion architecture adapters and ports.

    Röviden: alkalmazásnak mindig van API ja. Amin keresztül commandokat queryket tud befogadni. 

    Ha van API, akkor ahhoz egy adaptert írni, egy olyan logikai vagy fizikai réteget, mely egy adott csatornán (http, pipe, amqp, email, sms stb) bejövő parancsokat be tud injektalni az alkalmazás API jaba, elméletileg ujjgyakorlat.
    Mutasd a teljes hozzászólást!
  • Köszönöm szépen az ötletet! Kár, hogy nem ismerem a SendMessage VB-scriptes változatát, majd utána nézek... Ha Te tudsz a szkriptes változatról egy kicsit többet, mindenképpen érdekelne...
    Mutasd a teljes hozzászólást!
  • Bocs, lehet, hogy elnagyoltan fogalmaztam...  (Nem biztos, hogy tökéletesen használom a szakszavakat...) Nyilván attól, hogy egy -üzeneti értékkel bíró kód -a küldő alkalmazás kezdeményezésére- bekerül egy környezeti változóba vagy egy fájlba, vagy akár a registry-be, ettől ez még csak egy halott információ... Mivel én nem ismerem a fogadó program objektuma(i)hoz-, így azok tulajdonságaihoz- vagy metódusainak indításához való hozzáférés lehetőségét, azt az elvet választottam (egyenlőre), hogy az irányító szkript elhelyez egy parancs-információt egy megbeszélt helyre (pl. környezeti változóba vagy fájlba), és a fogadó program -a tőle telhető leggyakrabban- megnézi, van-e csomagolva valamilyen 'üzenet' a számára. Ha talál ilyet, akkor azt -a közös szótár alapján- értelmezi, és ha tudja, végrehajtja, majd ugyanerre a helyre (környezeti változóba vagy fájlba) ő is becsomagolja a saját visszajelzését: pl. megtaláltam (az új) parancsot-, tudtam-, vagy nem tudtam értelmezni, teljesítettem vagy nem teljesítettem, stb.

    Mivel az irányító szkript -a saját parancs-információjának a becsomagolása után várakozó ciklusba kezd, és ő is gyakorta nézegeti a megegyezett környezeti változót vagy fájlt, a kiolvasott visszajelzés értelmezésével el tudja dönteni, mit tegyen a továbbiakban...

    Hát, én így gondoltam a parancs- és visszajelzés információk -adott- txt fájlba csomagolgatásának a 'technikáját'. Ennek a módszernek a révén a szkript és a program -a vártnál gyorsabban-, (átlagosan 20 ms alatt) tudnak üzenetet váltani egymással. Ez így nekem (egyenlőre) már tökéletes, de gondolva a jövőre, érdekelnek a haladóbb módszerek is...
    Mutasd a teljes hozzászólást!
  • Köszönöm az információkat!
    Az igény -összefoglalva- az, hogy -akár házilag barkácsolt-, akár profi megoldással- az együtt futó (alapvetően vezérlési feladatokat ellátó script), és az (alárendelt rész-feladatokat ellátó) programocska kommunikálni tudjanak egymással, és a program azokat tegye, amiket a szkript kér tőle (mivelhogy szkriptek által nehézkesen-, vagy csak fapadosan megoldható feladatok ellátására készítettem)...

    Mi tagadás, irigylem, hogy Te ismersz az én barkácsolt kommunikációmnál (nevezetesen, hogy a szkrpit egy fájlba dugossa a parancs-információt, a programocska pedig -ha éppen ráér- belekukucskál a fájlba: jött-e új parancs), szóval ennél profibb módszereket... Érdekelne (2 mondatban összefoglalva):
    1) mi a lényege az API-nak, és az azt kiszolgálni hivatott logikai vagy fizikai rétegnek, amellyel injektálni lehet a kívánatos utasításokat?
    2) és az is, hogy ezzel az API-s (és a hozzá írt rétegelt) megoldással bármilyen programhoz hozzá lehet férni, ami exe kiterjesztéssel bír, Winows-on fut, és ember készített, vagy csak egy szűkebb körben lehet ezzel irányítgatni...?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd