Opnet open animation viewer - opnet

Hi I am trying to use animation feature in opnet. For that I set the preferences to open animation viewer when the simulation starts. During the animation I am trying to call op_anim_viewer_open which always returns -2. No more subsequent GUI call has any effect. I also do not really know what name should i put into viewer id paramaeter of the call. Especially when animation is only stored in file for later usage. Any advice?

Erasing all temporary files in user home resolved the problem.

Related

Preview handler dll permissions issue

I'm creating a preview handler dll for a custom graphics file type associated with an application I've developed. For various reasons the preview handler dll is not able to render the graphic for the preview itself. Instead I'm attempting to do it in the following way.
My graphics application associated with the file has been modified to accept specific command line parameters (file path, width, height). With these parameters the application loads the file, renders an image and saves it as a .png file in the user's AppData/Roaming folder and then terminates. This works fine if I call the application from the command line with valid parameters. The .png is created as expected.
When the preview handler is run it calls the application with command line parameters for the file being previewed and dimensions of the preview pane. It does this using the windows function CreateProcess and waits for the application to terminate before continuing.
The preview handler then loads the .png file and draws it to the preview pane.
The problem I'm experiencing is in the second step. The preview handler calls the application but the application gives an error that it is unable to save the .png file ("Cannot create file. Access is denied"). It seems that the application is being run with less permissions when executed by the preview handler than when I run it myself from the command line.
I have tried changing the save location of the file such as user's AppData/Local the shared ProgramData folder and the application's location, but all give the same result. I've also tried setting various CreationFlags in the call to CreateProcess, but none of them help.
Does anyone know why the application doesn't have permissions to save a file when called from a preview handler and is there anything I can do to get it to work? I realise that this is an unusual way of implementing a preview handler, but it's the easiest way without porting a lot of code. Another advantage is that I'm not replicating the rendering code in the main application and the preview handler, which means that the preview handler can be much smaller.
Note that I'm running on Windows 10.
Does anyone know why the application doesn't have permissions to save a file when called from a preview handler and is there anything I can do to get it to work?
Per the documentation:
Preview Handlers and Shell Preview Host
Preview handlers are called when an item is selected to show a lightweight, rich, read-only preview of the file's contents in the view's reading pane. This is done without launching the file's associated application.
...
By default, preview handlers run in a low integrity level (IL) process for security reasons. You can optionally disable running as a low IL process by setting the following value in the registry. However, it is not recommended to do so. Systems could eventually be configured to reject any process that is not low IL.
HKEY_CLASSES_ROOT
   CLSID
      {YOUR HANDLER'S CLSID}
         DisableLowILProcessIsolation
Another advantage is that I'm not replicating the rendering code in the main application and the preview handler, which means that the preview handler can be much smaller.
I would suggest moving the rendering code into a DLL. Export a function that takes a file name/pidl/stream and a target HDC as parameters. The function can read from the file and draw to the HDC as needed. The main app and the preview handler can then share the DLL, calling the function when needed to render the file directly to their respective UIs. You won't need to create a temp .PNG file at all.

Cannot complete download from popup when prompting location with saveAs

I've been working on a browser extension allowing users to generate epub files from any webpage.
To use the extension, a user has to click on a toolbar button which opens a popup. On the latter, after specifying a config, the user clicks on "Generate". Here is my issue though:
When I use the download API directly, and specify saveAs to false (i.e the user is NOT prompted where to save the file), then the download is completed as expected and the file saved in some location.
However, when I do set saveAs to true --- which is what I want in the final version --- then once the user has selected the location under which to save the file, the download fails. My intuition is that as soon as the file location window pops up, the popup looses focus and dies, which makes the download impossible to resume.
Is that the explanation? And is there a way to prevent such a problem? I do not find my use case to be much of a stretch, and do not get why popups associated with browser actions are not allowed to loose focus for file selection.
Another weird thing is that I'm pretty confident this problem only appeared recently in firefox, since when I started developing the extension, I had no issue.
My intuition is that as soon as the file location window pops up, the
popup looses focus and dies, which makes the download impossible to
resume.
That's right...
Browser Action Popup is page and once page is closed, async operations will lose their reference. It is best to pass async operations to the background script.
You can use
runtime.sendMessage()
to pass a message to the background script to run the download.
You can also use the async
runtime.getBackgroundPage() to run a function in the background script but the first option works
easier as you dont need to wait for the async response as in runtime.getBackgroundPage()

Controlling How Documents Stack when Opened

When some programs are opened they automatically cascade (when not opened in full screen), and I want to keep all documents directly on top of each other. I found this which claims that it is impossible.
I know that it can be done by having AutoHotkey watch if newly opened windows are not touching a border and moving it to the closest border, or to watch the position of the window when it is activated. Does anyone know of a good way to solve this using e.g. AutoHotkey?
The only working solution I have found so far is using DisplayFusion, which solves this using the setting
"window location". Here’s a short guide. I also found that there is a way to script it using the same program.

Handle GUI window changes

I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.

Can the last opened file location be directly altered?

As I understand it, when a file open dialog box (such as GetOpenFileName) is used, Windows will automatically remember where the last file was that was opened by the program, and Windows remembers these locations separately for each program. Is there a way to directly alter this, in order to cause the file picking dialog for program X to start in C:\Example\Directory?
I'm attempting to automate a program which has been programmed to work only through a GUI, and I don't have any access to the internals of this program (such as being able to alter how it calls the file picker). Instead, I'm using a mouse macro (via AutoHotkey). If I can be completely sure that the file picker will start in a particular place, I should be able to automate the rest with mouse clicks.
If you had access to the source code, I'd suggest you just change the lpstrInitialDir property of the OPENFILENAME passed to GetOpenFileName().
Outside of that, you'll want to change the registry keys for the MRUs:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
What might make more sense, and might fix the issue you're having, is also changing the Working Directory so that the default location isn't "My Documents", if you're experiencing that.
Depending on the operating system, the results vary:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx

Resources