I want to open two separate Minitab application from my .Net application and want to execute command seperately for two charts that will be displayed in coressponding Minitab application.
I tried with following but it returning same handle which refer to same application.
MtbApp1 = new Mtb.Application();
MtbApp2 = new Mtb.Application();
Minitab automation is not what you might expect. By design, I think the assumption is that any code you write will be to augment an existing user session of Minitab. So if the Minitab UI is open at the time you make the first call, the handle would be to that session and you could do stuff with the same workbook/sheets.
The second call would open a new process. Similarly, if there is no UI open before your code executes and you added a third new Mtb.Application() call, a second process would appear with a new handle. The minitab help file on automation has some information about the options, but doesn't seem to cover this little detail.
Related
I am beginner in using Visual FoxPro. I am trying to create a simple application which contains a form with a few textboxes. The problem is that the application window does not appear when I run the executable file which I build.
The code for the program is:
PROCEDURE main_app
_SCREEN.Activate
_SCREEN.WindowState = 2
_SCREEN.backcolor = RGB(128, 128, ;
128)
_SCREEN.Caption = ""
_SCREEN.refresh()
SET TALK OFF
SET DELETED ON
SET EXCLUSIVE OFF
CLEAR ALL
CLEAR
CLOSE ALL
DO FORM simpleform LINKED
READ EVENTS
RETURN
*MESSAGEBOX('Msg')
ENDPROC
In the form I have a few textboxes and a button. When the button is clicked then some code is executed. If I run the application from the IDE everything works fine but if I create the executable this does not display any window, still the process appears in the task manager. If I uncomment the MessageBox then this will appear even if I run the exe file. I don't know a way to trace the problem outside the IDE, maybe there is still a library needed that I am not aware.
I am using Visual FoxPro 9.0
Would someone be able to help me out?
If you can provide me with a link to a very simple application exe which uses just one form and finishes when the form is closed I would very much appreciate it.
Thanks in advance
I tried creating a brand new project, new code and new form just as you described. I copied your code and ran, but it never displayed the form.
If this is the main app in your project, you don't need the initial
PROCEDURE main_app
just remove this line as there is nothing CALLING the "Main_App" and thus is never getting called to ultimately call your form.
Just comment it out, save your project and run it... See what you get, it SHOULD work.
** PROCEDURE main_app
The problem was that I did not set the screen visibility to true.
I'm using VS 2013 with CodedUI to automate UI tests on an application that is not built by my client (it's an implementation project). When inspecting the UI Control using inspect or coded UI, I see that the Automation ID keeps changing and I have no real way (beside position based) to capture my controls (the application is developed in Delphi).
So I'm wondering if there exist some library or add-ons (or something not even related to Coded UI and VS) that can help with this? For example some tools that can capture a screen shot of the control and then map it (the screenshot) to an Control Id that I will define and use that to automate?
Wow....I was able to find a way to do what I need using sikuli (http://www.sikuli.org/) checkout this post. Ill actually try it out tomorrow. But I found on the web (link below) that it`s possible.
From Coded UI we can call the sikuli script like that:
Process process = new Process();
ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.FileName = #"D:\Sikuli\ds.bat";
process.StartInfo = startInfo;
process.Start();
process.WaitForExit();
(code from) https://answers.launchpad.net/sikuli/+question/232233 , read this post guys!
I have a D2006 app in which the DPR file has had numerous edits (yes, I know - you shouldn't mess with the DPR file) to accommodate such things as a splash screen, preventing a second instance of the app being started, handling of command line options that need to be processed before any forms are created, etc.
One day, I noticed that the auto-create forms list in the project options is empty - but the DPR file still has the code in there to create some of the forms.
If I try to restore all the forms that should be auto-created from the dialog, it complains Error - Call to Application->CreateForm is missing or incorrect and doesn't do anything.
How can I restore this connection - apart from rebuilding the DPR from scratch?
is it safe to manually add the CreateForm calls?
are there any documented rules as to what you can do in the DPR file?
I have a suspicion that try..except and if..else clauses in the DPR upset Delphi. Will moving as many functions as possible to a separate unit and calling them be helpful?
I haven't really seen any documented rules as to what you can do in the DPR file, because I guess there are no strict rules.
The problem begins when you create a "Forms" application. (No problems with console or non-GUI applications I've noticed).
The IDE will automatically change the DPR any time you add a new Form or a DataModule to it, by assuming you want to auto-create them.
This can mess up your DPR, if it has a lot of code/compiler-directives/if-blocks/try-catch blocks etc...
So I'll tell you what my rules are, and in a short line:
Keep it as simple as you can.
My DPR contains only a call to some init code and auto creates the main form only:
MyAppInit; // in AppInit unit
Application.Initialize;
Application.CreateForm(TMainForm, MainForm);
Application.Run;
However in the uses section I add (or keep what the IDE added) all the forms my application uses (and also application related units) - this is useful when I want to view->forms or view-units.
In-fact when I add a new form to the application, the first thing I do is go the DPR and remove the line:
Application.CreateForm(TMyNewForm, MyNewForm);
NOTE (EDIT): The IDE can be configured to NOT auto create forms (No Application.CreateForm entry will be created in the DPR). In older version of Delphi this option is under: Tools/Environment Options/Preferences -> Auto create forms. In newer versions: Tools/Options/VCL Designer/Module creation options -> Auto create forms & data modules.
At run-time, I create all my forms dynamically when I need them, and destroy them when they no longer needed. DataModules/Splash (etc...) are created on the MainForm.OnCreate event.
This method has worked for me nicely for the past few years maintaining a large scale DB application. This will probably not cover all cases, but it worked fine for my needs.
P.S: "Is it safe to manually add the CreateForm calls" - Yes. But think twice if you really need them to be auto-create by the application.
IMHO You don't really need that AutoCreate forms from Delphi, but maybe in the casual test project.
And the dpr is just another source code file, where you're meant to write code to make things happen (or prevent it to happen), so don't worry if you lost that sincronization, which IMHO is buggy if can't read your pascal code to work properly.
If you still want to create some forms from the DPR, add the Application.CreateForm or TMyForm.Create calls manually to the file, AFAIK there's no rules against doing it that way.
Since Delphi owns the .DPR, I put my startup logic into a separate unit for each project.
That works really well, only very few entries need to be in the .DPR.
Since that unit controls the Application.CreateForm logic too, the IDE has an empty list for that: I'm fine with that.
The only things left in the .DPR are:
the big uses that indicates which modules are part of your project
a call to Main in the startup logic unit
I have a browser based test program for testing a browser based application. This means that I need to record sequences that alternately manipulate the test program and then the application to check that it reacts correctly, so that I can perform automated testing.
How should I do this with SAHI?
I cannot see a way of recording two separate URL's concurrently. I have tried combining the two UI's using frames, and iframes, but I couldn't get SAHI to record in the frame/iframe.
I could modify the test program so that I can call it from scripts called by SAHI, but that rather defeats the object of having an automation tool...
Any suggestions?
1) Record the actions on the first web page using Sahi (script1)
2) Record the actions on the second web page (script2)
3) In script1, do this
// do steps for UI 1 as recorded in script1
_call(window.open("second url", "newWindow")); // open the second window
_selectWindow("newWindow"); // target the following steps on newWindow
// copy steps from script2 here
_selectWindow(); // return to base window
// perform further base window steps
// Use _selectWindow("newWindow") and _selectWindow() to switch between windows.
Hope this helps.
Regards,
I have a single-page web app that presents a multi-step photo management "wizard", split up across several discrete steps (photo upload, styling, annotation, publishing) via a tab strip. On switching steps I set the URL hash to #publishing-step (or whichever step was activated).
How do I set up Optimizely tests to run on the various discrete steps of the wizard?
The browser never leaves the page, so it only gets a single window.load event. Its DOM isn't getting scrapped or regenerated, but just switches what page elements are visible at any one time via display: none or block, so the part I am trying to figure out is really mostly about in what way I go about the Optimizely test setup itself - it's fine (and likely necessary) if all edits get applied at once.
This thing unfortunately has to work in IE9, so I can't use history.pushState to get pretty discrete urls for each step.
There's actually several ways you could go about doing this, and which option you choose will largely depend on what's easiest for you AND how you plan to analyze the data.
If you want to use Optimizely's analytics dashboard:
I would recommend creating one experiment which will activate a bunch of other experiments at different times. The activation experiment will be targeted to everyone and run immediately when they get to your wizard. The other experiments will be set up with manual activation and triggered by this experiment.
The activation experiment would have code like:
window.optimizely = window.optimizely || [];
function hashChanged() {
if(location.hash === 'publishing-step') {
window.optimizely.push(['activate', 0000000000]);
}
if(location.hash === 'checkout-step') {
window.optimizely.push(['activate', 1111111111]);
}
}
window.addEventListener('hashchange', hashChanged, false);
Or you could call window.optimizely.push(['activate', xxxxxxxxx]); directly from your site's code instead of creating an activation experiment and listening for hashchange.
If you want to use a 3rd party analytics tool like Google Analytics:
You could do this all in one experiment with code similar to above, but in each "if" section instead of activating an experiment, you could run your variation code that makes changes to the wizard and sends special tracking information to your analytics sweet for later reporting. You'll have to do your own statistical significance calculation for this method (as Optimizely's data won't be "clean"), but this method actually works out better usually if properly configured.
Alternatively you could use the method outlined above but still try to use the Optimizely analytics dashboard by creating custom events on your experiment and sending data to them using calls like window.optimizely.push(["trackEvent", "eventName"]);
This article may also be helpful to you.
You'll probably need to do this yourself, using Optimizely's JS API to trigger actions on their end and tell it what your users did: https://www.optimizely.com/docs/api