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.
Related
I am trying to find a way to create a form in PowerShell without using any variables unless they are temporarily or virtually assigned. I want to be able to run a command similar to this:
(New-Object System.Windows.Forms.Form).ShowDialog()
where I can enter in a code into an event that is triggered once the form is created. That event will then be responsible for creating all the objects and other events inside the form. Once the form is launched, I will not need any variables accept for the ones that are virtually assigned within the events.
This to avoid using too much system resources from assigning and endless amount of variables for each object in the form. The script that I am currently working on in PowerShell is very possibly going to be really big, and even if it is not a very large script, efficiency and clean code is always the key to writing a good program or script.
add-type -ass System.Windows.Forms
$x = (New-Object System.Windows.Forms.Form)
$x.Text = 'Message Box'
$x.Size = '300,150'
$x.Font = $x.Font.Name + ',12'
$x.Controls.Add((New-Object System.Windows.Forms.Label))
$x.Controls[-1].Size = $x.Size
$x.Controls[-1].Text = 'Here is a message for you'
$x.ShowDialog()
Remove-Variable x
It is very possible to access these objects still with the exact same kind of access when you define each object with a variable. It cost me many hours of research and just simply attempting random commands to find out how to do this. Here is all the commands you may need to relearn if you are interested in my solution:
# create item in form:
$x.Controls.Add((New-Object System.Windows.Forms.Button))
# access the last created item in the form:
$x.Controls[-1]
# change it's name to identify it easier
$x.Controls[-1].Name = 'button1'
# access the item by it's new name:
$x.Controls['button']
# delete the item by it's name:
$x.Controls.Remove($x.Controls['button1'])
If your familiar with form creation in PowerShell then this should all make sense to you and you should be familiar with how the rest of it works. Also, another note to make for those who are interested in what I am trying to do is that any of these commands can be done within an event by replacing $x with $this. If it is inside an event of an object inside the "controls" section of the form, then you would use $this.parent.
This is exactly what I mean by having the ability to create a form with virtually no variables. The only problem I am having with this is that I am unsure how to assign an event and call the method ShowDialog() at the same time.
I found an a very interesting solution to this, however I am not sure to what the limits are to this solution and it dose not quite work in the way that I would personally like it to.
file.ps1:
add-type -ass System.Windows.Forms
$x = (New-Object System.Windows.Forms.Form)
$x.Text = 'Message Box'
$x.Size = '300,150'
$x.Font = $x.Font.Name + ',12'
$x.Controls.Add((New-Object System.Windows.Forms.Label))
$x.Controls[-1].Size = $x.Size
$x.Controls[-1].Text = 'Here is a message for you'
$x
remove-variable x
command to execute the code:
(iex(Get-Content 'file.ps1'|out-string)).ShowDialog()
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.
I am currently starting a Service in my C# code using WMI, and I would like to set its startup parameters.
Is there a way to do this? I couldn't find anything relevant so far.
Thanks in advance.
Thomas.
These other posts helped me to solve my issue :
https://superuser.com/questions/809868/wmi-startservice-parameter
Dynamics AX 2012 RegConfig does not work
Check the open source project
Services+
Contains full usage of WMI with StartService
Example VB.Net:
Dim objPath = "\\ComputerName\root\cimv2:Win32_Service.Name='ServiceName'"
Using objService As New ManagementObject(objPath)
Dim outParams = objService.InvokeMethod("StartService", Nothing)
rtnVal.WmiValue = CInt(outParams)
End Using
From matlab it is possible to get a (java) reference to the matlab editor using these commands:
desktop = com.mathworks.mde.desk.MLDesktop.getInstance;
jEditor = desktop.getGroupContainer('Editor').getTopLevelAncestor;
Thanks to Undocumented Matlab
Does anyone know how to get a reference to the Command Window?
It is impossible to obtain it the same way as the group titles do not include 'Command Window'
cl = desktop.getGroupTitles()
cl =
java.lang.String[]:
'Editor'
'Figures'
'Web Browser'
'Variables'
'Comparison Tool'
'Help'
'Time Series Plots'
'Scopes'
Perhaps like this?:
desktop = com.mathworks.mde.desk.MLDesktop.getInstance;
cmdwin = desktop.getClient('Command Window');
Maybe you need to add this too:
cmdwinview = cmdwin.getComponent(0).getViewport.getComponent(0);
h_cmdwin = handle(cmdwinview, 'CallbackProperties');
All of this comes from this forum thread: http://www.mathworks.com/matlabcentral/newsreader/view_thread/257842.
Remark: I am not a MATLAB/Java guru. Google, on the other hand, I can use :)
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!