Forum Discussion
There are only a few limited ways of calling code across projects. Adding units as existing items, plugins, and script extensions. Consider a project as a "compiled" application. Everything that project needs to be able to be run needs to either be contained within or able to be referenced by that project. So, if your UI plugin is necessary to run your tests, you need to include it...or, find some other method of getting the same functionality the plugin provides to your other project.
Hi ,
if you look at the applications now especially on the larger projects/products all are built with one or more technologies.we went through the support documents and concluded that we could call routines from one project to another. so we have used ui plugin for one technology with in the product. and for other without ui plugin . Now the integration of both has come up and we have to automate that. because of the above limitation we couldn't complete the project.
SmartBearDan could any of the smart bear staff give us the workaround or any other way to call routines from different projects which uses different properties . this would help us to save the time.
if no,t i strongly suggest, you should change your document by adding this limitation as most of the automation engineers will decide the project strategy by looking at your support documents.
- tristaanogre8 years agoEsteemed Contributor
I am sure SmartBear folks will come back with an official response. But the article you linked in your OP specifically talks about including units from one project to another by adding them as existing items, essentially making them common libraries of code. Nothing is mentioned in that article about what happens if those units are dependent upon a particular UI plugin. Basically, to use something across multiple projects, you need to include it in multiple projects. So, if you have an item that has a dependent on a particular plugin and you are including that item in another project, that other project is now also dependent on that plug in. To make it even simpler... in Project1 if I have Unit1, Unit2, and Unit3 and Unit3 calls functions from Unit1 and Unit2, if I add Unit3 to Project 2, I also need to add Unit1 and Unit2 as well otherwise Unit3 will fail. This is not a matter of plugins, it's a matter of context. Such is the case, really, in any technology.
For example, in Netbeans when I'm developing java applications, if in one application I create a class that is dependent upon having a particular jar included in the project, if I take that class to a different project, I must also include that jar in that project. I can't just expect the class to work in the new project if I don't bring over it's dependencies as well.
That's basically the scenario you created. Your tests and code and such in your first project are dependent upon a particular plug in.... to use them in a different project, you need to bring that plug-in along for the ride. I don't know exactly what the plug in is, who created it, etc... but if you have code dependent upon it, that code will not work if the plug-in is not present.- ramefi8 years agoOccasional Contributor
i too agree with and the netbeans example but here the project suite is already loaded in and all plugins in everywhere except in current project setting.
s if there would be any options to change the current project settings during the run i could turn on the ui plugin for that routine only which is inherited from another project.
I am not sure whether test complete has the feature to access current project properties during run time so then we could change the object explorer behavior .
- tristaanogre8 years agoEsteemed Contributor
The project suite may be loaded in, but properties and objects are not shared within projects within a suite...each project, effectively, stands on it's own with the suite serving as a vehicle to contain them and order their execution. So, even if the project with the plugin is in the same suite, that plugin must be enabled in every project where it is needed.
As for what you are asking... I don't think there is... Options of TestComplete in general can be accessed and changed (in a limited fashion) by using the Options object... but you are talking about Project.Properties... once a project has started running, it is, effectively, "compiled" and you can't change the properties of the project on the fly.
What it sounds to me is that you may need to re-write the routine to detect, somehow, if the plugin is present and, if it is not, to behave in a different way. Things like aqObject.IsSupported could be employed, perhaps, to make that determination...
Related Content
- 2 years agoianlop
- 7 months agomacheshmeh
- 12 months agoIso_Yura
- 2 years agoḼari
Recent Discussions
- 5 hours agoMW_Didata