Author Topic: Inline Function to kickoff a command from another profile on profile change?  (Read 2985 times)

Starblue7

  • Full Member
  • ***
  • Posts: 131
I have a profile #1 that has a command with an inline function (C#) (Code Below) that I'm trying to have it detect a profile change to another profile #2, and post that change, identify the command in Profile #1 to execute.
Profile #1's commands are included in the set from Profile #2 per the 'Profile Options' VA Menu.

So far, the below code runs begrudgingly and identifies when the profile changes and successfully loops through all profiles, but it won't execute the command.  Which it seems it can't find.

I'm relatively new to INLINE and C# and everything that's going on.  Indeed this is my first attempt at a write-up (taking some examples from the forums).

At some point, I'd prefer to rely on the GUID of Profile #1 and Profile #2 along with any other mandatory flags as some static determination rather than having to loop through all profiles to find the one with the command.
Any guidance on that and how I can set those flags for my own Voice Attack Profile (That will persist) is very welcome.

If someone could help guide me along with this and try to be gentle for any doofus mistakes or if my skull is too thick to grasp what you all may think is deadly obvious.  Much appreciated!

Code: [Select]
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

public class VAInline
{
public void main()
{
VA = vaProxy;
string profileName = VA.Profile.Name();
VA.ProfileChanged += new Action<Guid?, Guid?, string, string>(ProfileChanged);
ProfileChanged(null, null, "", "");
}
public void ProfileChanged(Guid? FromInternalID, Guid? ToInternalID, String FromName, String ToName)
{
foreach (string profileName in VA.ProfileNames()) // Loops through each profile to find the one with the command I want to run.
{
string CommandName = profileName.Replace("[", "").Replace("]", "") + "POLLING ON"; // This is the command name within the profile 'SC Custom Profile' that I wish to run after profile is switched to a different profile.
if (VA.Command.Exists(CommandName))
{
if (profileName != VA.Profile.Name()) //Don't execute the initialization command for the active profile
{
VA.Command.Execute(CommandName, false);// Execute and wait for command to complete
VA.WriteToLog("Command kicked off in profile: " + profileName);
}
}
}
VA.WriteToLog("Profile Changed " + FromName + " " + FromInternalID + " to " + ToName + " " + ToInternalID);
}
}


SemlerPDX

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 280
  • Upstanding Lunatic
    • My AVCS Homepage
First of all, you are correct that you can take advantage of the profile flags to help you manage the flow of switching between these profiles. In particular, I use the {PROFILE_AT1}, {PROFILE_AT2}, and {PROFILE_AT3} flags to help identify the version, name, and ID of my profiles.

You can also make use of the profile options for execution, to make each of your profiles execute any command within them if they are switched to, and also the option to execute any command within them when they are switched FROM (to another profile). This can help you establish variable values that may be needed by a "hub" or "main" profile that controls these other profiles.

You can also programmatically detect the profile flags of the profile being switched from and switched to, using {PREVIOUSPROFILE_AT1}, {PREVIOUSPROFILE_AT2}, and {PREVIOUSPROFILE_AT3} - or {NEXTPROFILE_AT1}, {NEXTPROFILE_AT2}, and {NEXTPROFILE_AT3}.

Regardless of any of this, no existing command can be executed unless it is already an active profile, or that profile and its commands are referenced globally in VoiceAttack options (as a Global Profile) or locally from within the Profile Options of the active profile.

I use a "hub" profile myself which I call AVCS CORE, where the actual "game" profiles depend upon that main profile for initialization, common functions, and relative common commands (as they pertain to that game profile and the game it is for).  All the 'game' profiles must have the "hub" or "main" profile included through their individual Profile Options menus. This lets them execute an existing command (by name) which is present in that "hub" or "main" profile.

If a "game" profile is switched to, a command executes which checks if the "main" profile exists, and then switches to it to initialize the game profile - that "main" profile reads the {PREVIOUSPROFILE_ATn} flags to identify the "child" game profile and the data to load, and then loads itself, the game profile, and finally switches back to the game profile which executes that initialization command one last time (though this time, with a "MyProfileInitialized" boolean as 'true' thus exiting it when initialized, instead of switching to the "main" profile).

The way you are parsing through all profiles is not at all efficient, and if your logic and flow was more thoughtfully designed, not at all necessary.


Not sure if any of this helps, but it's one way you can use all these tools so that a governing "main" profile can have all the information it needs about the "child" profiles it controls.

Starblue7

  • Full Member
  • ***
  • Posts: 131
Thanks for the long reply.  It was informative and has made me think even further about what I'm actually trying to accomplish here.

I'm currently experimenting if I can get my INLINE function to behave how I want it before I give up and just go full on and try to make some plugin....