I use the following script to create the plugin (gtk), but after I run the script, I do not know where is the created plugin (gtk) file?
I checked the folder
C:\Program Files (x86)\Gatan\DigitalMicrograph\PlugIns
I do not know see any new created gtk file in the folder.
Is this script wrong or the created gtk file should be in somewhere else?
/ Define the necessary variables string base,menu,submenu,item,packageNAME,name
number maxitem,i,j,maxfolder taggroup tgFILES,tgFOLDERS,tg
// Just some starting text in the results window.
result("\n Automatic Installation of all scripts in a folder as Plugin:\n\n")
// First get the default folder. (In this case, the folder last opened within DM)
base = GetApplicationDirectory(2,0)
// Prompt the user with a dialog to choose a folder, with the default folder as first choice.
// If the user cancels the dialog, the script will stop.
If (!GetDirectoryDialog("Please select the folder containing the scripts",base,base)) exit(0)
// Ask the user for a package name
If (!GetString("Name of package file?","",packageNAME)) exit(0)
// Ask the user for a menu name
If (!GetString("Name of menu to install the scripts in","",menu)) exit(0)
// Get all files/folders in the folder as a tag-list
tgFILES = GetFilesInDirectory(base,1)
tgFOLDERS = GetFilesInDirectory(base,2)
// Install all files from the main folder as menu commands.
// Count Items in the folder
maxitem = tgFILES.TagGroupCountTags()
i = 0
// Loop through all items
while (i<maxitem)
{
// get taggroup of item
tgFiles.TagGroupGetIndexedTagAsTagGroup(i,tg)
// get name of file
tg.TagGroupGetTagAsString("Name",item)
// Only if filename end with ".s" continue
If (right(item,2)==".s")
{
// use the name without the ending
name = left(item,len(item)-2)
result("\n Installing: "+item)
// install the menu command
// use the Try-Catch loop to detect problems during install
try
{ AddScriptToPackage(base+item,packageNAME,0,name,menu,"", 0) }
catch
{ result(" \t ERROR DURING INSTALL") } }
i++ }
// Now install all files from sub-folder as sub-menu commands.
// Count subfolders in the folder
maxfolder = tgFOLDERS.TagGroupCountTags()
// Loop for all subfolders
for (j=0;j<maxfolder;j++)
{
// get taggroup of item
tgFolders.TagGroupGetIndexedTagAsTagGroup(j,tg)
// get name of subfolder which is also the name of the submenu
tg.TagGroupGetTagAsString("Name",submenu)
// Get all files in the subfolder as a tag-list
tgFILES = GetFilesInDirectory(base+submenu,1)
// Count Items in the folder
maxitem = tgFILES.TagGroupCountTags()
i = 0
// Loop through all items as before for the main folder
while (i<maxitem)
{
tgFiles.TagGroupGetIndexedTagAsTagGroup(i,tg)
tg.TagGroupGetTagAsString("Name",item)
If (right(item,2)==".s")
{
name = left(item,len(item)-2)
result("\n Installing <"+submenu+">: "+item)
try {
AddScriptToPackage(base+item,packageNAME,0,name,menu,submenu, 0) }
catch
{
result(" \t ERROR DURING INSTALL") } }
i++ } }
You are probably running into the "Compatibility files" feature of Windows 7. GMS 1.x has only one variant of the AddScriptFileToPackage function and it always wants to save the resulting package file to the standard DM PlugIns folder:
C:\Program Files (x86)\Gatan\DigitalMicrograph\Plugins
But in Windows 7, such direct writing of files to subfolders of the Program Files directory is prevented and files are instead written to a user-specific local directory named as follows:
C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files (x86)\Gatan\DigitalMicrograph\Plugins
However, one can easily make such virtualized files visible by clicking on the "Compatibility files" button that appears in the tool bar of the Windows explorer window for the standard PlugIns folder.
This depends a little on the GMS version and the OS version you're running on. I assume you're using GMS 2.x on a Windows7 or Windows8 machine, then the command AddScriptFileToPackage can have two syntax versions:
void AddScriptFileToPackage( String file_path, String packageName, Number packageLevel, String packageLocation, String command_name, String menu_name, String sub_menu_name, Boolean isLibrary )
void AddScriptFileToPackage( String file_path, String packageName, Number packageLevel, String command_name, String menu_name, String sub_menu_name, Boolean isLibrary )
in the first version packageLocation could be user_plugin or plugin. If this parameter is omitted (2nd command version) then user_plugin is assumed.
For user_plugin you will find the created file in:
C:\Users\USERNAME\AppData\Local\Gatan\Plugins
where USERNAME is the current windows user.
For plugin you will find the created file in the 'plugins' subfolder relative to the installation of the 'DigitalMicograph.exe', most likely in:
C:\Program Files\Gatan\Plugins
Related
The following example shows a very simple construction for creating a PDF with MigraDoc. The most parts of it are taken from the examples provided in the MigraDoc - Wiki documentation.
I have commented all the most few steps for the job. The path for the "AddImage" points to the subfolder "Images" which is a subfolder of the folder "Resources" created in the root of the console application of a Visual Studio (VS) project.
The most recent MigraDoc library is added to the VS - project via "NuGet" just yesterday.
The application creates the PDF output file unfortunately without the provided image file, if it is used in another machine. Because the execution file has then no access to the subfolders created in VS project.
Is there any solution to this problem?
public class Program
{
static void Main(string[] args)
{
// Create a MigraDoc document
var document = new Document();
// Add a section the document
var section = document.AddSection();
// .....
/*
------------------------------- NOTE -------------------------------
The path "../../Resources/Images/MigraDoc.png" is valid only for the developer machine!
A copy of the content of the "Debug" or "Release" folder any where else does not show the image in the output PDF.
Because such a copy has no access to the subfolder "/Resources/Images" of the Visual Studio project on the developer machine.
*/
section.Headers.Primary.AddImage("../../Resources/Images/MigraDoc.png");
// Create a renderer for PDF that uses Unicode font encoding.
var pdfRenderer = new PdfDocumentRenderer(true);
// Set the MigraDoc document.
pdfRenderer.Document = document;
// Create the PDF document.
pdfRenderer.RenderDocument();
// Save the PDF document...
var filename = "Invoice.pdf";
// Create the output directory
Directory.CreateDirectory("PDF");
// Create the ouptput file path
var savePath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\PDF\\" + filename;
// Delete the output file if it already exists
if (File.Exists(savePath))
File.Delete(savePath);
// Save the output file
pdfRenderer.Save(savePath);
// Start a the default PDF viewer from the operation system
Process.Start(savePath);
}
}
A path beginning with ..\..\ relies on the current directory. For a portable solution, include the images you need in your deployment.
Recommended usage: The MigraDoc Document class has an ImagePath property. If your installation folder has an Images folder, just locate your .EXE file and set the ImagePath property accordingly.
An eclipse plugin is needed to allow users to input a script and run that script through the IDE. For this I've implemented an eclipse plugin, using the multi-page editor template. I added the extension org.eclipse.debug.ui.launchShortcuts and provided a reference to my implementation of the interface org.eclipse.debug.ui.ILaunchShortcut. This interface requires to provide an implementation of these methods:
public void launch(final ISelection selection, final String mode);
public void launch(final IEditorPart editor, final String mode);
When the user - e.g. me - right clicks the file from the project explorer, selects "run as" and selects the launcher I provided, then the implementation of this launch method is hit. The first method - i.e. the ISelection version - is hit when selecting the file from the project explorer. The second method - i.e. the IEditorPart version - is hit when right clicking the editor zone and selecting the launcher through the "run as" option from the context menu.
I now need to find out how I can retrieve the contents of that editor page. In the first method I believe I could retrieve the filename with the below code:
IFile file = (IFile) ((IStructuredSelection) selection).getFirstElement();
String path = file.getFullPath().makeAbsolute().toString();
However, the that path is relevant with respect to the root of the project. I don't know how to retrieve the path of the root of the project.
The implementation of the second method is more problematic given I don't know how to find the path based on the IEditorPart.
I hope you can help. Many thanks
If you are asking how to get the file that the editor is current editing you can use something like:
IPath filepath = null;
IEditorInput input = editor.getEditorInput();
IFile file = input.getAdapter(IFile.class);
if (file != null) {
filepath = file.getFullPath();
}
if (filepath == null) {
ILocationProvider locationProvider = input.getAdapter(ILocationProvider.class);
if (locationProvider != null) {
filepath = locationProvider.getPath(input);
}
}
which tries to get the IFile frpm the editor directly and if that fails tries for a location provider.
I've seen a few questions asking if it's possible to check if a specific download is completed, or if a specific download has been completed successfully. (to which the answer appears to be no.)
What I want to know: Is it possible to see if selenium is currently downloading any file? I.e. it doesn't matter if it's one file, or 20. Something like a small boolean check would be ideal.
When chrome is downloading a file you can check your downloads folder for the temp file (*.crdownload) that Chrome uses. When the download finishes that file is "replaced" by the actual filename/type.
/// <summary>
/// Looks for a file with the given extension (Example: "*.crdownload") in the current user's "Download" folder.
/// </summary>
public static string LocateDownloadedFile(string fileExtension)
{
// Get the default downloads folder for the current user
string downloadFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile) + "\\Downloads";
DirectoryInfo di = new DirectoryInfo(downloadFolderPath);
FileInfo[] filesFound = di.GetFiles(fileExtension);
if (filesFound.Length == 0)
{
// do stuff
}
else
{
// do other stuff
}
}
I am currently working in a WiX/Burn Managed Bootstrapper Application and cannot figure out how to get the local path for a payload (MSI).
I let the user select which applications they want to install in my custom UI, and I want to not show applications for which the MSI is missing. I also need to see information in the MSI's database.
I know I can determine missing payloads by handling "ResolveSource" but that doesn't happen until right before the application in installed.
I deserialize the BootstrapperApplicationData.xml file first thing so I have information about which MSIs MIGHT be installed, but it still doesn't help me determine the source of the MSIs.
Does anyone know how to determine the local path to a payload?
EDIT: Here is an example for how I reference all the installers:
<MsiPackage Id="AppName"
SourceFile="$(var.ProjectName.TargetDir)ProjectName.msi"
Name="MSI\ProjectName.msi"
Compressed="no"/>
In the GetLastUsedSourceFolder function in cache.cpp, you can see that the engine gets the source folder from the WixBundleLastUsedSource variable, and the parent directory of the WixBundleOriginalSource variable if WixBundleLastUsedSource isn't set.
You can use this along with the Name attribute of the WixPayloadProperties element in the BootstrapperApplicationData.xml file to predetermine where the engine will look for a payload. Note that the engine will actually look in the cache first.
The MSI files are embedded into the bundle .exe and aren't extracted from the bundle until right before the application is installed, which corresponds to when the ResolveSource event fires. However, if you really want to get this information, you can programatically extract the MSI files yourself and inspect them using the WiX DTF library (wix.dll in the /bin folder of your WiX install).
using Microsoft.Tools.WindowsInstallerXml;
private void ExtractEmbeddedMsiInstallers()
{
var tmpFolder = Path.Combine(Path.GetTempPath(), Path.GetRandomFileName());
var bundlePath = Engine.StringVariables["WixBundleOriginalSource"];
Unbinder unbinder = null;
try
{
unbinder = new Unbinder();
//The next line will extract the MSIs into the tmpFolder in a subfolder named "AttachedContainer"
unbinder.Unbind(bundlePath, OutputType.Bundle, tmpFolder);
}
finally
{
if (null != unbinder)
unbinder.DeleteTempFiles();
}
}
You also mentioned needing to inspect data in the MSI database. Here's a sample of how to do that:
using (var database = new InstallPackage(msiFilePath, DatabaseOpenMode.Transact) { WorkingDirectory = _someTempFolder })
{
if (database.Tables.Contains("CustomAction"))
{
using (View view = database.OpenView("SELECT `Action`, `Type`, `Source`, `Target` FROM `CustomAction`"))
{
view.Execute();
foreach (Record rowRecord in view)
using (rowRecord)
{
var actionName = rowRecord.GetString(1);
var actionType = rowRecord.GetInteger(2);
var binaryName = rowRecord.GetString(3);
var methodName = rowRecord.GetString(4);
//Do something with the values
}
}
}
}
I need to generate a temporary file, fill it with some data and feed it to an external program. Based on description of D available here I'm using File.tmpfile() method:
auto f = File.tmpfile();
writeln(f.name());
which doesn't provide a way to get the generated file name. It's documented that name might be empty. In Python I would do that like this:
(o_fd, o_filename) = tempfile.mkstemp('.my.own.suffix')
Is there a simple, safe and cross-platform way to do that in D2?
Due to how tmpfile() works, if you need the name of the file you can't use it. However, I have already created a module to work with temporary files. It uses conditional compilation to decide on the method of finding the temporary directory. On windows, it uses the %TMP% environment variable. On Posix, it uses /tmp/.
This code is licensed under the WTFPL, so you can do whatever you want with it.
module TemporaryFiles;
import std.conv,
std.random,
std.stdio;
version(Windows) {
import std.process;
}
private static Random rand;
/// Returns a file with the specified filename and permissions
public File getTempFile(string filename, string permissions) {
string path;
version(Windows) {
path = getenv("TMP") ~ '\\';
} else version(Posix) {
path = "/tmp/";
// path = "/var/tmp/"; // Uncomment to survive reboots
}
return File(path~filename, permissions);
}
/// Returns a file opened for writing, which the specified filename
public File getTempFile(string filename) {
return getTempFile(filename, "w");
}
/// Returns a file opened for writing, with a randomly generated filename
public File getTempFile() {
string filename = to!string(uniform(1L, 1000000000L, rand)) ~ ".tmp";
return getTempFile(filename, "w");
}
To use this, simply call getTempFile() with whatever arguments you want. Defaults to write permission.
As a note, the "randomly generated filenames" aren't truely random, as the seed is set at compile time.