Contributions
Re: VCL Objects detected as Window objects
This is a old thread but I just find out the steps of this "issue" (maybe it is a bug) (tested on TestComplete 15.45.31.7 x64) TestComplete opened, no project loaded: On Both Object Spy and Object Browser, VCL objects of the application appear as VCLObject As soon as a project is loaded without the application in TestedApps: On Both Object Spy and Object Browser, VCL objects of the application appear as "Window" objects As soon as the application is added into TestedApps within the same project On Both Object Spy and Object Browser, VCL objects appear as VCLObject So the "workaround" (maybe it is a bug) is to ensure that the application is in TestedApps object of your project or no project is opened at all.10 months agoPlace TestComplete QuestionsTestComplete Questions310Views2likes1CommentHow to remove ID-Based login from TestComplete/TestExecute
I just switched from license key to ID-Based licensing for TestComplete/TestExecute For a test, I used login name/password when I launched the application in order to test. But my goal with TestExecute PCs is to use Access Key. Even by uninstalling and reinstall TestExecute or TestComplete, the last ID is still used and I don't find anything in doc or in software to remove the last ID. Even switching between Lisence Key and ID-Base didn't work, it still uses the last ID. Is there a way to clear ID base login info in app? Thanks238Views0likes1CommentVCL Objects detected as Window objects
I found some old posts about VCL Objects detected as Window objects in TestComplete but they are from old versions of TC (like 10). I'm using 15.45 The tested applications are compiled using C++ Builder. The problem is, when I start my application, TC sees all application's objects as Windows objects This is not really handful when I want to add new tests and the windows aren't detected correctly. But the test is defined to find VCL objects using "FindEx", "Find" and "FindAll" methods. So as soon as I run at least one defined test and it needs to find a VCLObject, the magic happens, now all objects are seen as VCL ones. Even if I let both TC and app opened for a while or even refreshing the Object Browser, it didn't change anything What could be the root cause this detection issue? I can workaround it like described here but if I can get rid of this, it would be great. Thanks!Solved602Views0likes4CommentsAbility to change OCR BlockByText() message level
The function OCR.BlockByText always post a warning message in the log when 2 or more occurences of a text is found. The ability to change the error level will help to keep a clean log report when we are expecting multiple occurences of a text. Could be by adding an optional parameter at the end of the function to specify the message level which is defaulted by "warning". Ex: OCR.Recognize(myObj).BlockByText("test", spNone, lmWarning);231Views0likes0CommentsRe: WaitWindow() method on InstallShield software object make it crashing intermittently.
Edit: When I was calling the method where this function is used, the number of parameters wasINcorrect, and some of those parameters were used on the method, that could possibly result to unknown behaviors...746Views2likes0CommentsRe: WaitWindow() method on InstallShield software object make it crashing intermittently.
mattbwrote: I am not aware of something like this causing crashing, though if it is we can open a support ticket! For a short term fix I would recommend a waitproperty() on a object within the windowhttps://support.smartbear.com/testcomplete/docs/reference/test-objects/members/common-for-all/waitproperty-method.html I commonly use the visible property. Before opening a ticket, I wanted to know if someone faces that kind of issue (before or currently) But finally, I think I found the root cause (I say "think" since since this issue is occurring occasionally). When I was calling the method where this function is used, the number of parameters were correct, and some of those parameters were used on the method, that could possibly result to unknown behaviors... For now, so far so good but time will confirm. Thanks all!748Views1like1CommentRe: WaitWindow() method on InstallShield software object make it crashing intermittently.
And unless you are testing installer itself, why not to install the product from command line without UI? AlexKaraswrote: And unless you are testing installer itself, why not to install the product from command line without UI? Something like: msiexec /i <yourProduct.msi> That's sadly the point, we also test the installer 🙂 But that's a good solution for those who are not!746Views0likes0CommentsWaitWindow() method on InstallShield software object make it crashing intermittently.
Has someone here experienced a tested application to sometimes crash when using the WaitWindow() method on an object? This occurs intermittently when we use it on InstallSheild software. We got the error event "The setup.exe process has crashed" and the call stack of the event points out to the WaitWindow() call. As I said, this is not occuring all the time and I didn't identified yet if it always occurs on the same object Just want to know if there is something known about that with this method. Thanks a lot!Solved814Views0likes5CommentsRe: Javascript Classes vs. //USEUNIT
Thanks Marsha_R I already read this page and didn't found answers that I wanted. BUT, I think I found a workaround that will limit the use of "require" in one file only. So if //USEUNIT only imports global variables and functions, so why not put the "require" statement within it's own file and then use //USEUNIT to import it? //File A var AClasses = require("A"); class MyClass { constructor(x) { this.x = x; } GetX() { return this.x } } module.exports.MyClass = MyClass; //File B //USEUNIT A function test() { var myObj = new AClasses.MyClass(5) //Works! } IMO, this is a more cleaner way if we want to use the class in multiple units, we just need to use //USEUNIT instead of declaring another variable in each file.978Views0likes1CommentJavascript Classes vs. //USEUNIT
I was a little bit surprised when I tried to create an object from a class located in another file within the same project when this file is imported using //USEUNIT and got a reference error //File A class MyClass { constructor(x) { this.x = x; } GetX() { return this.x } } //File B //USEUNIT A function test() { var myObj = new MyClass(5) //Or var myObj = new A.MyClass(5) //Will throw "Reference Error: MyClass is not defined" } I read couple of posts in this forum and, the fact of using "module.exports" and "require" seems (in my opinion) to defeat the purpose of //USEUNIT that I currently use to import global variables and functions from other units which works very well and makes code clean. But unfortunately, classes from other files aren't imported using //USEUNIT. Is it a known limitation of the implementation of Javascript through TestComplete? A limitation of the engine? A bug? A misunderstanding of my own? Thanks to help me see a little bit clearer on that.Solved1.1KViews0likes4Comments