store macro as variable?

[gechu]

.. and later invoke it?

[Pako]

Can you explain, what you do you need ?
Preferably with some example.

Pako

[gechu]

My goal is to enable a seamless transition from one application to another. I have actually managed to fix, but it was not a very nice solution. More info about it is available here: http://www.eventghost.org/forum/viewtop ... f=2&t=3871

Back to this problem. Imagine this scenario:

1. Load remote key preset for XBMC
2. Store the exit macro for XBMC into a variable called "PreviousApplication"
3. Use XBMC ...
4. Then you want to switch to Dscaler, and presses the button that triggers the remote key preset for Dscaler
5. The first line in the initialization macro for Dscaler contains the action which executes the "PreviousApplication" macro (BTW, the same action should be preset in every init macro like XBMC as well)

[Pako]

Unfortunately, I still do not understand. Maybe just because I do not speak English.
However, I especially do not understand why you do not use a common mechanism enable/disable.
I am convinced that it is possible to use to solve your problem.

Pako

[gechu]

Hi Pako and thanks for trying to get the point of my question. I realize my way of explaining isn┬┤t the best. Anyhow, let┬┤s try again. I use a context folder (exclusive folder) to set different configurations for my remote.

In each application specific folder available in my context folder, I only want to keep macros related to a particular application. Example: "app A" context folder should only contain stuff related to "appA", and "appB" should only contain stuff related to "appB".

Let┬┤s assume the currently running application is called "appA" (with corresponding remote configuration set), and the next one is called "appB". When a button is pressed that triggers an event which loads a macro for setting the remote configuration for "appB". What I want to do is to set the new configuration for appB, but also terminate the previously running application (appA). And this is where I have my problem. How do I access that macro if that remote configuration is not "active" anymore?

I tried to create an event in each context folder named something like "Close". Then before I load the new configuration, I could simply trigger the event Close and it would close the currently running application. Problem was that the "set new configuration" command is executed before the triggering of the "Close" event even though the triggering of the "Close" command is before the "set new configuration" command in the macro sequence.

So I thought, when I┬┤ve loaded a new configuration, then I store that configuration┬┤s "close" macro to a variable to always have access to it.

Does my explanation make sense?

[Livin]

You've asked this question before inanother thread you started on June 3rd.

I tried to help but you basically told me I was an idiot who did not understand your problem... which is funny since now one of the 3 most knowledgeable people for EG (Pako) does not get what you are trying to do. Pako, I guess you are dumb just like me. -- just kidding brother

Genchu, a large portion of how you are trying to do things is overly complicated, not necessary, and in this case not possible... thus, shows you have a fundamental misunderstanding of how EventGhost is designed and intended to work. Hint, Hint: You need to read the wiki/docs and re-read my previous help and actually learn EG... Or just stop asking the same question and do things how you want and keep failing.

I gave you my XML which does exactly what you are trying to do... but the correct way, not "your" way.

So simply put...
Macros are not variables - they cannot be stored in variables (If you don't believe me, go learn how to code a language and then get back to me)
The easiest and cleanest way to solve your problem is to use a combination of Enable/Disable and Triggers (just as I do in the XML I gave you)

Closing and opening apps is dead simple... changing context for them is dead simple... combining the workings of those is dead simple.

Don't bother responding directly to me in this thread, I'm not going to check it, or follow it. And Pako... you have two choices here... find a brick wall and talk to it, or try to explain this to Genchu - your result will be the same.

[blaher]

2. Store the exit macro for XBMC into a variable called "PreviousApplication"

Just copy and paste the 'XBMC2: quit' action into the root directory of your EventGhost tree, (and assign it a button press trigger), then it won't matter whether the XBMC or dscaler context folders are enabled or disabled; if XBMC is running, it will be closed.

[gechu]

Thank you blaher, that is indeed a way to solve the problem.

In my case I have about 4 different applications in my context folder. And none of the applications will have to run at the same time, so just like you suggested, I┬┤ll simply create a macro in the root which looks like this:

Remote.ButtonX.Event
Winamp.Close
XBMC.Close
Dscaler.Close
TopSetBox.Close

The dirty part is of course that applications which isn┬┤t running will try to get closed, but the simplicity of this solution compared to my existing one sure is interesting.

[jonib]

In my case I have about 4 different applications in my context folder. And none of the applications will have to run at the same time, so just like you suggested, I┬┤ll simply create a macro in the root which looks like this:

Couldn't you keep the quit actions with the other macros for respective program, and then just put the button events you use to start the other programs to the quit macros.

So when you are using XBMC you press the Winamp start button it closes XBMC because the button event triggers XBMC.quit and also starts Winamp. But it won't try to close any other programs because they are not active.

You might need a slight delay in the program start macro so the other program has time to get the quit action.

Hopefully this rambling can be understood.

jonib

[blaher]

Thank you blaher, that is indeed a way to solve the problem.
The dirty part is of course that applications which isn┬┤t running will try to get closed, but the simplicity of this solution compared to my existing one sure is interesting.

You could eliminate that by looking at what Livin showed you, where you use the find window action, and if it doesn't, then you can stop the macro altogether.

Another way would be to have separate folders that were enabled and disabled based on just what was launching; again in Livin's .xml.

[gechu]

I┬┤ve taken a look at Livin┬┤s config once again. It has never been any doubt about that he has proposed a solution to the "switch between two applications" problem. What I didn┬┤t like in that solution was that in each context folder, I would have to add many different "trigger" commands for closing an application in a folder which had no relation to that particular application. It would look like this:

Code: Select all

Context folder appA
appB.close
appC.close
appD.close
appE.close

Context folder appB
appA.close
appC.close
appD.close
appE.close

Context folder appC
appA.close
appB.close
appD.close
appE.close

Context folder appD
appA.close
appB.close
appC.close
appE.close

Context folder appE
appA.close
appB.close
appC.close
appD.close

Of course I┬┤ve already spent way more time discussing how to find a better solution to the problem than it takes to configure all these "close" triggers. But I guess that is what easily might happen if you are enthusiastic about something.

blaher & jonib, when I read your comments this is the solution I think you are referring to:

Code: Select all

Global folder close
appA.close
appB.close
appC.close
appD.close
appE.close

I have not tried it yet, but I think (as jonib mentioned) that it will result in timing issues when you first want to close an application, and then quickly after that start it again. You could add a delayed start of the application, but I don┬┤t that is desireable because you want the experience to be as snappy as possible.


Regarding my initial question, store a macro in a variable, I know that it is not possible via the GUI, but I my thought was that you could access so much more functionality using the Python API, so why not a pointer to a macro?


Thanks for all the input so far!

[jonib]

blaher & jonib, when I read your comments this is the solution I think you are referring to:

Actually my proposal was more like Livins, but I kinda don't like repeating all those quit actions either. But I'm not sure there is a cleaner way to do it without complicating it unnecessarily.

I have not tried it yet, but I think (as jonib mentioned) that it will result in timing issues when you first want to close an application, and then quickly after that start it again. You could add a delayed start of the application, but I don┬┤t that is desireable because you want the experience to be as snappy as possible.

The delay would be very small so mostly not noticeable.

Regarding my initial question, store a macro in a variable, I know that it is not possible via the GUI, but I my thought was that you could access so much more functionality using the Python API, so why not a pointer to a macro?

If you need a pointer to a macro just create for example a Jump action to the macro, then copy that action from EventGhosts config tree and paste to a text document. now you see the syntax for the Jump action, including a number to access the specific macro that you can store in a variable.

jonib

[gechu]

It smells victory!! ;D Thanks jonib!

[jonib]

It smells victory!! ;D Thanks jonib!

It went bad, that's why it smells I posted about a big problem with the pointer to a macro here.

jonib

[gechu]

Turned out I don┬┤t need to access macros this way. In my config I set a global variable to the name of the currently active application. It is for example used to abort execution if an already started application is triggered again, and instead bring it to front. Anyhow, when I know the name of that application, and have a globally available macro which follows this naming pattern: "application".Close, then it is simple to construct and trigger the relevant ┬┤"close event".