Winamp with gen_scripting in Jscript - plugins

Using the gen_scripting plugin for Winamp you must instantiate the object. In VBS this is
Set winamp = CreateObject("gen_scripting.WinAmp")
However, I'm pretty sure that the same plug-in can be used to script Winamp using Jscript (or possibly even Javascript - a better choice for me). So, I've tried
var winamp = Object.create("gen_scripting.WinAmp");
x = winamp.GetVersion();
alert(x);
winamp.ButtonPlay;
Only that doesn't work. Any help to get me started would be appreciated

JScript analog of VBScript CreateObject() is new ActiveXObject().
Also, alert is a browser-specific function; in Windows shell scripts you should use WScript.Echo.
var winamp = new ActiveXObject("gen_scripting.WinAmp");
var x = winamp.GetVersion();
WScript.Echo(x);
winamp.ButtonPlay();

Related

Get Word's window handle to use with WPF windows

I have a number of WPF dialogs in my Word Add-In. For one of them (and only one, strangely), it is sometimes not focused when opened. I believe I need to set its parent.
I know there is a way to set the owner of a WPF window to a HWND, but is there any way to get a HWND in Word 2010? I found this HWND property but it is Word 2013 and later only. Is there any other way to get Word's HWND, other than using GetForegroundWindow() which does not guarantee the handle for the window I actually want (or any other similar kludge)?
I found something helpful in Get specific window handle using Office interop. But all those answers are based on getting the handle for a window you're newly creating. I modified it somewhat to get an existing window, and stuffed it into a utility method.
doc is the current document.
using System.Windows.Interop;
using System.Diagnostics;
public void SetOwner(System.Windows.Window pd)
{
var wordProcs = Process.GetProcessesByName("winword").ToList();
// in read-only mode, this would be e.g. "1.docx [Read-Only] - Microsoft Word"
var procs = wordProcs.Where(x =>
x.MainWindowTitle.StartsWith(Path.GetFileName(doc.FullName))
&&
x.MainWindowTitle.EndsWith("- Microsoft Word"));
if (procs.Count() >= 1)
{
// would prefer Word 2013's Window.HWND property for this
var handle = procs.First().MainWindowHandle;
WindowInteropHelper wih = new WindowInteropHelper(pd);
wih.Owner = handle;
}
}
Unfortunately it doesn't seem to be possible to account for multiple windows with the same document name (in different folders), because the number of processes is never greater than 1. But I think that's an acceptable limitation.

Add-CMDeploymentType warning

Im using poweshell to automate creating applications in SCCM 2012, distributing content and deploying them once created.
I have the following code:
New-CMApplication -name $appname -Manufacturer $manu -SoftwareVersion $ver
Which works fine.
However.
Add-CMDeploymentType -MsiInstaller -applicationName $appname -AutoIdentifyFromIntallationFile -InstallationFileLocation $content -ForceForUnknownPublisher $true
Gives me a warning " Failed to get install type's technology and it won't create the deployment type.
As far as I can tell from other sites, I shouldn't need to specifiy and more than that. I've experimented with adding more options on the end but none seem to make a difference.
There isnt very much out there about this error - has anyone got past it before?
I doubt that you'll get Add-CMDeploymentType to do much useful -- at least not in its current form. I once tried and gave up when I noticed that it is missing basic, essential parameters. The documentation does not even mention, for example, detection of any sort. There's not much point in using ConfigMgr Applications without detection, and there's not much point in scripting the creation of DeploymentTypes if you still have to define the detection criteria via the UI.
You might get the odd msi file configured using the Add-CMDeploymentType's AddDeploymentTypeByMsiInstallerX parameter set. In that case you'd be relying on ConfigMgr to work out the detection logic automagically. That may work, but I have had significant issues with the MSI Deployment. I'd avoid that if possible.
I'm not hopeful that the Add-CMDeploymentType will ever become usable. The object tree that underlies Applications is necessarily complex and really doesn't lend itself to interaction using simple PowerShell cmdlets. To completely configure an Application there are hundreds of properties on dozens of objects that you need to access. Many of those objects are contained in dictionary- and array-like collections that have their own special semantics for accessing them. You just can't simplify that into a handful of PowerShell cmdlets.
I'm using the types in the following .dlls to interface with ConfigMgr:
AdminUI.WqlQueryEngine.dll
Microsoft.ConfigurationManagement.ApplicationManagement.dll
Microsoft.ConfigurationManagement.ApplicationManagement.MsiInstaller.dll
As far as I can tell, that is the same API the admin console uses, so you can expect full functionality. You cannot make the same claims about the PowerShell cmdlets. So far I have found a way to access everything I've tried through that API using PowerShell. The basics of accessing that API is documented in the ConfigMgr SDK. It's fairly straightforward to figure out how those objects work using reflection and some experimentation.
When you retrieve an Application using Get-CMApplication you actually get the full object tree with it. The SDMPackageXML object contains a serialized copy of the Application, DeploymentTypes, detection, installers, etc. [Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer]::DeserializeFromString() works to deserialize that object so you can inspect it for yourself.
I actually gave up on this - As you say - Add-CMDeployment type is completely useless. There was nothing online anywhere that described this error, or how to use it properly - an Application with no detection is pointless and adding it manually later defeats the point in trying to automate it.
PowerShell centre had some examples of how it could be used but neither of these worked...
This link was pretty useful and has everything I needed to create an application without powershell.
link
a bit long but the code was...
Public Sub create_SCCM_application(appname As String, version As String, content_location As String, filename As String, manu As String)
Try
Dim appID As ObjectId = New ObjectId("ScopeId_devscope", "Application_" & Guid.NewGuid().ToString())
Dim app As New Application(appID)
app.Title = appname
app.Version = "1.0"
app.Publisher = manu
app.SoftwareVersion = version
app.AutoInstall = True
Dim dinfo As New AppDisplayInfo
dinfo.Title = appname
dinfo.Version = version
dinfo.Language = Globalization.CultureInfo.CurrentCulture.Name
app.DisplayInfo.Add(dinfo)
Dim dtID As ObjectId = New ObjectId("ScopeId_devscope", "DeploymentType_" & Guid.NewGuid().ToString())
Dim dt As New DeploymentType(dtID, MsiInstallerTechnology.TechnologyId)
dt.Title = appname & " Deployment type"
dt.Version = "1.0"
app.DeploymentTypes.Add(dt)
Dim installer As MsiInstaller = dt.Installer
Dim fakecode As Guid = Guid.NewGuid
installer.ProductCode = "{" & fakecode.ToString & "}"
installer.InstallCommandLine = "msiexec /i " & filename
installer.UninstallCommandLine = "msiexec /x " & filename
installer.AllowUninstall = True
installer.ExecuteTime = 30
installer.MaxExecuteTime = 30
installer.ExecutionContext = ExecutionContext.System
installer.UserInteractionMode = UserInteractionMode.Hidden
installer.DetectionMethod = DetectionMethod.ProductCode
installer.ProductVersion = version
Dim appcont As Content = New Content
installer.Contents.Add(appcont)
appcont.Location = content_location
Dim msifile As New ContentFile
msifile.Name = "_temp.msi"
appcont.Files.Add(msifile)
Dim appxml As XDocument = SccmSerializer.Serialize(app, True)
Dim appinstance As ManagementObject = Nothing
Dim path As ManagementPath = New ManagementPath("SMS_Application")
Dim options As New ObjectGetOptions
Dim appClass As ManagementClass = Nothing
Dim scope As ManagementScope = New ManagementScope("\\devserver\root\Sms\Site_devsitecode")
appClass = New ManagementClass(scope, path, options)
appinstance = appClass.CreateInstance()
appinstance.Properties("SDMPackageXML").Value = appxml
appinstance.Put()
Catch x As System.Exception
Console.WriteLine(x.Message)
End Try
End Sub
Your question regarding the deployment type behaviour is also wierd - We have that same product and it works from an MSI deployment type.

Convert C# logic to powershell for TFS

I have a C# program which build me a TFS build definition. I want to do the same code in a powershell script. So far, I have been able code the script which will create me a new build definition in TFS. However, I have trouble setting Process section of the build definition. I need to convert the below code in C# to powershell and all attemps I have made did not work.
//Set process parameters
var process = WorkflowHelpers.DeserializeProcessParameters(buildDefinition.ProcessParameters);
//Set BuildSettings properties
BuildSettings settings = new BuildSettings();
settings.ProjectsToBuild = new StringList("$/Templates/Main/Service/application1");
settings.PlatformConfigurations = new PlatformConfigurationList();
settings.PlatformConfigurations.Add(new PlatformConfiguration("Any CPU", "Debug"));
process.Add("BuildSettings", settings);
buildDefinition.ProcessParameters = WorkflowHelpers.SerializeProcessParameters(process);
First I loaded the assemblies I need to work with TFS. When I want to replicate the same C# code as,
var process = WorkflowHelpers.DeserializeProcessParameters(buildDefinition.ProcessParameters);
I did following in PowerShell
$process = New-Object Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers.
Above gave me an error saying "Constructor not found. Cannot find an appropriate constructor for type Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers"
I checked and there are no constructors for that. My question is what I am I doing wrong in writing the PowerShell script to achieve the same functionality as c# code. I am sure it's syntax error that I am doing and not aware of the correct way of doing it in PowerShell.
It would appear from your code snippet (and confirmed via MSDN) that the DeserializeProcessParameters is a static method on the WorkflowHelpers class. You would need to invoke it with the following syntax in PowerShell:
$process = [Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers]::DeserializeProcessParameters($buildDefinition.ProcessParameters)
It looks like the buildDefinition variable is declared earlier - so I just stuck a $ character on it to make it a legit PowerShell variable. Same thing with the process variable. I hope this helps!

Windows Automation with Matlab

Hello I'm trying to control FastHenry2 via Windows automation with Matlab.
I'm new to that topic. If I understood everything right I have to open it:
ax=actxserver('FastHenry2.Document');
and than run the function I want with the handle?
ax.Run('coils1.inp')
but that doesn't work. Matlab can't find Run and uses run instead, which is some build in Function not related at all with the problem. Also all other Function this UI should support don't work either. For Example FastHenry2.IsRunning or FastHenry2.GetInductance. So I guess I do something wrong with the whole UI handling. FastHenry provides an example script using VBS which I attached bellow and since it works fine FastHenry should be installed right on computer. I'm thankful for every hint I can get.
so long
eactor
The following VBS example works fine
Dim FastHenry2
pathPos = InstrRev(Wscript.ScriptFullName, Wscript.ScriptName)
path = left(Wscript.ScriptFullName, pathPos-1)
Set FastHenry2 = CreateObject("FastHenry2.Document")
couldRun = FastHenry2.Run("""" + path + "coils1.inp""")
Do While FastHenry2.IsRunning = True
Wscript.Sleep 500
Loop
inductance = FastHenry2.GetInductance()
WScript.Echo "Coils1 mutual inductance is " + CStr(inductance(0, 0, 1))
FastHenry2.Quit
Set FastHenry2 = Nothing
You might need to use an alternate syntax. Instead of
FastHenry2.Run('coils1.inp')
try this.
invoke(FastHenry2, 'Run', 'coils2.inp')
I've had to do this for some methods on the Excel.Application ActiveX control. I'm not clear why the first syntax doesn't work in some cases.

Classic ASP: Server.CreateObject not supported

When I call Server.CreateObject(), from my Classic ASP page, I get
Microsoft VBScript runtime (0x800A01B6)
Object doesn't support this property or method
I've tried the following (separately):
Server.CreateObject("Microsoft.XMLHTTP")
Server.CreateObject("MSXML2.XMLHTTP")
Server.CreateObject("MSXML.DOMDocument")
I know the ActiveX objects are installed because the following javascript calls work
var test = new ActiveXObject("Microsoft.XMLHTTP");
var test = new ActiveXObject("MSXML2.XMLHTTP");
var test = new ActiveXObject("MSXML.DOMDocument");
I'm calling it from my localhost IIS server. Any ideas how to troubleshoot this?
If you do the following:
Dim x: x = Server.CreateObject("My.ProgID.Here")
...VBScript creates the object and then attempts to access the default property for storing in 'x'. Since none of these objects have a default property defined (specifically an IDispatch-based property with [id(DISPID_VALUE)]), this fails with "Object doesn't support this property or method".
What you actually want is this:
Dim x: Set x = Server.CreateObject("My.ProgID.Here")
How about this one?
Set xml = Server.CreateObject("MSXML2.ServerXMLHTTP")
Or downloading this component and installing on your webserver?
http://www.microsoft.com/downloads/details.aspx?FamilyId=3144B72B-B4F2-46DA-B4B6-C5D7485F2B42&displaylang=en
Then restarting the server and trying again.
Calling them from the browser doesn't mean that they are installed in IIS.