Contributions
Indicator interference
We are running into problems with the TestComplete Indicator. When it covers a control it seems to truly make that control's VisibleOnScreen property become [false]. Has it always done this? It seems like it would but what confuses me is that we have been using TestComplete (TC) for years and it is only now becoming a problem (on Win7, TC8.7). Some of our people seem to think that it is not interfering on XP systems. Did TC used to somehow make the Indicator get treated as if it were invisible prior to Win7? In many cases we can get around this by moving TC over to another monitor that is not the main one for the program being tested or is not even used by the program being tested. However, we prefer to have our clients run TestExecute, and there does not appear to be a way to get TE to show the Indicator anywhere but on the main monitor. That will be a huge problem for us. I know that we can apparently do Indicator.Hide() to make the indicator disappear, but it is very useful for giving clues that the test is not in an endless loop, or to indicate where the test is in its overall run. So, my questions: * Has the indicator changed so that it is no longer "invisible" and thus affects the VisibleOnScreen of controls under it? * Is there a way to move the Indicator? It would be nice to move the indicator to the taskbar or some neutral part of the monitors. Thanks, Rob19KViews0likes2CommentsDirectly opening a file via [Download] during a review
I am having a difficult time trying to find out how to "customize" the [Download] button at the top of the screen that shows the code being reviewed beside the code being compared to (a previous version). I tend to like to see the code in an editor like NotePad++ on a full screen instead of in the narrow panes that CodeCollaborator provides. I use the [Download] button a lot. Normally it lets me immediately open the file into NotePad++, because I have my system setup so that when I "open" a code file (.sj, .scpp, ...) it opens into Notepad++. I am having a problem doing that with ".bat" files. When I click [Download] when reviewing a ".bat" file then CodeCollaborator gives me the option to "Run|Save" instead of "Open|Save". I did try to "temporarily" switch the system to associate Notepad++ with ".bat" files, just like I did with other code files. It does not seem work. Not only that but it is very difficult to switch the system back to "normal" behavior (disassociate Notepad++ from ".bat" files so that double-click is meant to run them...I have to go into the registry to undo this. It's a Win7 machine). It seems to me that this might be a common issue. Code files may be setup to open into the programmer's favorite tool normally (e.g. Visual Studios or such) but when using [Download] in CodeCollaborator most of us don't want to "Run" the file or have to download it somewhere, then go to that place and finally get to open it in whatever editor/viewer we use when reviewing code. With bat files I want to be able to double-click on them and have them run, but when I [Download] from a review, I want to edit them (not run them). Is there a way to configure CodeCollaborator itself so that it will open the reviewed file in Notepad++ (or whatever program I want) rather than using the system association for the file type (or whatever it is doing right now by default)? If yes, then would you please provide the instructions as to how to do it. If no, then might this be a useful enhancement to consider for the future? Thanks, Rob9.6KViews0likes0CommentsGetting TC/TE versioninfo and/or process without Sys.Process()
Hi, I've been wanting to ask something likethis for a while but have just now had someone actually encounter a situation where it is needed rather than "would be nice to know". Is there some way of getting information such as VersionInfo or executable-pathfor the currently running TestComplete/TestExecute without going through the process of calling Sys.Process(), and using that process object to finally extract what we want? The surprise that I had today was that someone was trying to run both TC7 and TC8 on the same machine. They were comparingtests in order to convert them. The problem was that the scripts used Sys.WaitProcess("TestComplete") to get the process and then extract the VersionInfo. However, the retrieved process was for the alternate TC and thus the version was misleading. Thanks.21KViews0likes1CommentWin7 (64bit) Compatibility-mode and registry
Hi, We have been moving some of our testing onto Win7 (64bit) machines and were having problems. We were hoping that updating to TC8.7 would solve these problems, but it did not (at least not initially). We recently discovered that flagging TC to run in "Windows XP (Service Pack 3)" compatibility-mode seems to fix many of our problems on Win7 (64-bit). HOWEVER, running in compatibility-mode seems to cause a new problem. I've tried searching TC help and the forums but there does not seem to be much, if any, mention about using compatibility-mode in Win7, so I am now asking for help. What we are seeing is that accessing the registry is now VERY slow. If you run the following test-code on Win7 (64-bit), with TC8.7 you can see a huge difference in how fast each iteration of the for-loop takes. When TC is NOT in compatibility mode then the iterations are fast (but then we have our other problems). When TC IS in compatibility mode then the iterations take about a second each. function Test_SearchRegistryForProgramPath() { var index = -1; var possible_path = ""; try { if( Sys.OSInfo.Windows64bit == true ) { // 64-bit registry_key = Storages.Registry( "Software\\Microsoft\\Windows\\CurrentVersion\\Installer\\Folders", HKEY_LOCAL_MACHINE, AQRT_64_BIT ); } else { // 32-bit registry_key = Storages.Registry( "Software\\Microsoft\\Windows\\CurrentVersion\\Installer\\Folders", HKEY_LOCAL_MACHINE, AQRT_32_BIT ); } for( index = 0; index < registry_key.OptionCount; index++ ) { // Set a breakpoint on this line. possible_path = registry_key.GetOptionName( index ); } return true; } catch( exception ) { return false; } } Thanks.17KViews0likes1CommentRe: Can we automate setup and reloading of CLR Bridge and path to Extensions?
Thanks for the prompt reply. Re: extensions. We have written our own extensions as well as making use of extensions from 3rd parties. It seems to me that your answer is the approach that we use when dealing with the 3rd party extensions. We use the same 3rd party extensions for all of our projects/suites. We never have to deal with 3rd party extensions via TC's [Tools]>[Options]>[Engines]>[Script Extensions] page because they don't change very often and can be stored in [...\Bin\Extensions\ScriptExtensions] as you said. That's easy. However, it's a different story when it comes to our own extensions. We generally have multiple sandboxes on our machines. One sandbox may contain the current release version of our projects/suites and one (or more) sandboxes may contain projects/suites that are under development. Each sandbox is meant to be "self-contained", so each has its own version of our extensions. We have to use TC's [Tools]>[Options]>[Engines]>[Script Extensions] page to specify where our extensions are. Every time that we switch from one sandbox to another we need to go to the [Script Extensions] page and change the path to our extensions folder in the sandbox that we are currently working in. If we forget to do that then we can easily run into problems since the extensions being used belong to a different sandbox than the one that we are working on. The [Script Extensions] page applies to TC and not specifically to the currently loaded project/suite, so switching to a project that is in a different sandbox does not automatically switch to the extensions that are found in that sandbox. Copying our extensions to [...\Bin\Extensions\ScriptExtensions] is not the answer (unless we set something up to copy the extension files from the sandbox to [ScriptExtensions] every time that we switch sandboxes. Yuck. We'd also still have to somehow reload/refresh the extensions after the copy, which would probably have to be done manually via [File]>[Install Script Extensions...]>[Reload]. I don't think that the [Script Extensions] page even allows you to use relative paths (though I may be mistaken). I guess that the question would be "relative to what?". If you change projects then you are changing your location and wouldn't that then necessitate recalculating the provided relative-path to your extensions? Since it is TC-related instead of project-related, I would think the relative path (if allowed) would have to be relative to the TC-folders rather than the project-folders. When our clients install our projects/suites, they create their own sandboxes. We have no control over (and don't want to try to limit them) what the sandbox paths are. They also may have multiple versions of our tests (since they are testing multiple versions of their software). It would be wonderful if there were some flexible way to have the tests run without them having to tweak TC first so that our extensions could be found. So, my original question was trying to find some way to automatically adjust the location where TC expects to find our extensions when we switch/load projects. It does not sound like TC can do this though it seems like it is a logical concept to investigate.893Views0likes0CommentsCan we automate setup and reloading of CLR Bridge and path to Extensions?
We want to allow our clients to run our tests without them having to know how to customize all the details (such as insuring that certain items are in the ClrBridge list for the project, or that the proper Extensions\bin is being referred to by TestComplete/TestExecute). The less that they have to do the better. Ideally, they should only have to run some installation programfor the project, and then run some batch-filewhenever they want torun the project, and then view the results. They should not have to be concerned in any way with tweaking the system so that TestComplete or TestExecute can find things. Our environment is one in which we may be switching between projects and/or versions of projects often. Two common issues that seem to come up are: * the need to go intoTC's [Tools]>[Options]>[Engines]>[Script Extensions] to adjust the pathso that TC/TE can findour extensions for that project and insure that they are reloaded. * the need to go into TC's [Tools]>[Current Project Properties]>[CLR Bridge] to insure that desired items are in the list and are reloaded. Each project may have different items in their lists. Is there any way to have access to the ClrBridge from within a script so that we can alter it and reload it (e.g. during initialization) to insure that it is automatically adjusted and up-to-date for the environment that the project is being run in? Is there some way to automate this sort of thing (via a batch-file or creating an exe or ...) so that it could be included in either the project-installation code or in the batch-file used to run the project? Thanks15KViews0likes3CommentsRe: Calling functions in a DLL from an extension
Hi, I'm confused again. In your example of the executable that loads the DLL into an assembly ("SampleAssembly") it looks like the EXE is a console program. Doesn't it need some MessageLoop to keep the EXE active and alert for requests? How are requests for the wrappers recognized/processed in the EXE (what's the code supposed to look like for this)? What should a wrapper function look like? How does the EXE call the DLL via the SampleAssembly? It would be very helpful to have a more complete example for the necessary EXE code. I assume that my script should be using the AppDomain approach to access this EXE, and then the EXE is to wrap calls to the DLL which has been loaded into the SampleAssembly object. I'm sorry for asking so many questions, but there is something that I am always missing. I keep getting more little pieces of the puzzle but it's like I have been building out from the corners. The chunks are getting bigger and growing towards each otherbut they are still disconnected. I need the pieces that will finish connecting the chunks and make it complete/workable. It seems like it should be simple. Maybe I'm mixing pieces from different puzzles/approaches.1.8KViews0likes0CommentsRe: Calling functions in a DLL from an extension
Well, I tried copying the function out of the extension and into my test-suite to see if the DLL.DefineEnvironmentByDLL()...Load()...dll_object.function() logic would work outside of the extension. I ended up getting to the point of trying to call the function and then got the exception "Object doesn't support this property or method". I did a google search on DefineEnvironmentByDLL and found someone else who indicated that they were having problems with this stuff in TC8 (though it had been working for themin TC7). http://www.sqaforums.com/showflat.php?Cat=&Board=UBB43&Number=639128&Searchpage=1&Main=638878&Words=+Allen_AQA&topic=&Search=true I am using TC8.10.487.7. The link did not provide a solution (they took the issue out to email so that's no help to anyone else). Anyone have suggestions? I also looked into trying to use the AppDomain() approach, which needs an EXE to wrap calls to the DLL. There are no examples about how to do that. What should the EXE code look like? Which templateshould be used for it?How does one start the EXEfrom an extension? The dotNET approach does work, but we have a lot of test-projects and really would like it if we did not have to maintain the CLRBridge in each of them just so the extension will work (all of the DLL calls are in the extension). Thanks for any consideration. ~Rob1.8KViews0likes0CommentsRe: Calling functions in a DLL from an extension
Thanks Julia. That clears things up a lot. My Test_Misc() function was in my extension and was my attempt to call functions in the LogGenerator.dll. I was hoping to be able to have only the extension need to know about the LogGenerator.dll. I wanted to free the projects that use the extension from having to know anything about the dll. It looks like there is a limitation in extensions that will not let me do that (since it sounds like I have to add LogGenerator.dll to the CLRBridge for each of my projects in order for the extension to be able to use dotNET to call the dll). That is what we were originally doing. However, that is forcing the writers of the projects to have to remember to add LogGenerator.dll to the CLRBridge of the project. We also seem to have problems getting the calls to LogGenerator.dll to work consistently. Sometimes reloading in CLRBridge helps and sometimes we have to remove and re-add LogGenerator.dll to the CLRBridge. This seems to be a lot of maintenance and it does not always fix the problem (I seem to get "[object Error] : Exception: [null]." a lot when I try to call LogGenerator.dll functions). Maybe we'll try creating an exe that wraps the calls to the dll, as you suggested. ~Rob1.8KViews0likes0CommentsCalling functions in a DLL from an extension
I'm using TC8.1, have created an extension, and am now trying to call functions in a DLL from the extension code. Initially we were adding the DLL to the CLRBridge of our main project (not the extension) and were using the dotNET object to call the functions in the dll. That seemed to work. Now we are using extensions and need to call the DLL from the extension code too. Actually, since some of the extension code needs to call the DLL, I've moved everything that needs the DLL into the extension. Now I am having problems calling the DLL functions. I originally tried adding the DLL to the extension's CLRBridge, and it did seem to work...sort of. It does not make sense to me that it should work at all since the tcx file for the extension only includes code files and the description.xml, so where would the CLRBridge info be included? I did read that there is a way to go around the CLRBridge by using AppDomain. However, it is not well documented (at least as far as whether it can be used with DLL's as opposed to exe's)...so I gave up trying that. I found another set of docs about calling functions in DLL's. It's complicated. You have to even prototype the functions that you want to call in the DLL, and you have to be careful about clearly specifying the types of parameters being passed. It seems to be like setting up the COM connections back in C++. I seem to have gotten through it but when I actually call a DLL function I get an exception "Object doesn't support this property or method." It does not matter whether I call a function that has no parameters or a function that has parameters. function Test_Misc() { var function_name = "reportservice_util_unit_test.Test_Misc"; var dll_path_name = "D:\\sandbox-v3-CopyLog\\Utilities\\LogGenerator.dll"; var dll_nickname = "LogGenerator"; var dll_environment = null; // Def_Environment in docs. var dll_type = null; // Def_DLL in docs. var dll_object = null; // Lib in docs. try { //########################################################################## // Define an environment (32-bit or 64-bit) for loading the DLL into. // In this case it should go into the 32-bit environment automatically since the DLL is 32-bit. //########################################################################## dll_environment = DLL.DefineEnvironmentByDLL( dll_path_name ); if( dll_environment == null ) { HelperForUnitTesting_TestFailed( function_name, "Unable to create an DLL Environment for [" + dll_path_name + "]." ); return false; } //########################################################################## // Get a helper object to use in defining the type of routines in the DLL. //########################################################################## dll_type = dll_environment.DefineDLL( dll_nickname ); if( dll_type == null ) { HelperForUnitTesting_TestFailed( function_name, "Unable to create an DLL Type for [" + dll_path_name + "]." ); return false; } //########################################################################## // Define the functions to expect in the DLL. // NOTE that first parameter is the FUNCTION_NAME. // NOTE that final parameter is the FUNCTION_RETURN_TYPE (use vt_empty or vt_void if no return value). //########################################################################## // No parameters. dll_type.DefineProc( "AppendEmptyLog", vt_void ); // Parameter1: ProjectName // Parameter2: Machinename dll_type.DefineProc( "CreateDateFolder", vt_lpstr, vt_lpstr, vt_void ); //########################################################################## //########################################################################## dll_object = dll_environment.Load( dll_path_name, dll_nickname ); if( dll_object == null ) { HelperForUnitTesting_TestFailed( function_name, "Unable to create an DLL Object for [" + dll_path_name + "]." ); return false; } // Try a routine that has no parameters. dll_object.AppendEmptyLog(); // Try a routine that has parameters. var project_name = dll_environment.New( "LPSTR", 256 ); var machine_name = dll_environment.New( "LPSTR", 256 ); project_name.Text = "TestingDLL"; machine_name.Text = "ABCD"; dll_object.CreateDateFolder( project_name, machine_name ); } catch( exception ) { HelperForUnitTesting_TestFailed( function_name, Messages_CreateMessageForException( exception ) ); return false; } HelperForUnitTesting_TestSucceeded( function_name ); return true; } I get the exception whether I call AppendEmptyLog() or CreateDateFolder(). Any help would be appreciated. Thanks.20KViews0likes6Comments