Не вводится текст методом Keys из Connected Application

Не вводится текст методом Keys из кода написанного в среде Visual Studio. Фокусируется на объекте, но текст не вводит. Присвоение значения свойству не подходит.
P.S.Причем из TC вводится нормально.

Код:
var tc = <полный путь к объекту>;
tc["Click"]();
tc["Keys"]("asdasd");

Не вводится текст методом Keys из кода написанного в среде Visual Studio. Фокусируется на объекте, но текст не вводит. Присвоение значения свойству не подходит.
P.S.Причем из TC вводится нормально.

Код:
var tc = <полный путь к объекту>;
tc["Click"]();
tc["Keys"]("asdasd");

Какой код получается при выполнении Record ?

Какой код получается при выполнении Record ?

Не понял вопрос. Если имеется в виду запись, то оно тут не причем. т.к. код написан в среде Visual Studio на языке C#. Запускаю тесты оттуда, а не из среды ТС.

Какой код получается при выполнении Record ?

Не понял вопрос. Если имеется в виду запись, то оно тут не причем. т.к. код написан в среде Visual Studio на языке C#. Запускаю тесты оттуда, а не из среды ТС.

Тогда Вам не в этот форум.
Для выполнения указанных действий TC выполняет много скрытых действий.
Например, для клика на объект берется его handle, вызываются соответствующий SendMessage, PostMessage и т.д.

Тогда в какой? Быть может не так выразился.
Я подключил в своем приложении библиотеки AutomatedQA TestComplete, и работаю с ними в среде VS. Меня интересует вопрос почему метод Keys в скрипте, написанном в среде ТС работает, а в VS - нет.

Здравствуйте.

А в момент выполнения теста, находится ли TestComplete в состоянии Playing? Если нет, то это и есть причина проблемы. Многие объекты ТС инициализированы и правильно работают только когда выполняется тест. Перевести ТС в этот режим без, собственно, запуска теста можно с помощью функции RunTest, которая описана в разделе справки Running Connected and Self-Testing Applications.

В нашем проекте не используется метод RunTest. Все скрипты составляются динамически, т.е. по некоторому сценарию. Если я правильно понимаю, данный метод предполагает наличие уже написанного скрипта. К сожалению это нам не подходит - наши тестируемые проекты очень часто меняют свою внутреннюю структуру, и пути к объектам соответственно тоже. Все методы и объекты прекрасно работают через класс Connect, почему же метод Keys не работает. Пока приходится обходится методом "SendWait" из класса "System.Windows.Forms.SendKeys" это из VS.

Здравствуйте.

Метод RunTest не требует наличия теста в проекте и вообще никакого теста не выполняет. Он просто переводит TestComplete в состоянии Playing. Это нужно для инициализации некоторых подсистем, которые могут существовать только при воспроизведении теста. Многие из этих подсистем настраиваются через свойства проекта, поэтому Вам необходимо в качестве параметров метода передавать настроенный проект.

Попробуйте использовать этот метод и сообщите помогло ли. Остановить тест можно с помощью StopTest.

Если я правильно понял: необходимо создать пустой проект на ТС и в методе RunTest ссылаться на него?

Здравствуйте.
Именно так.

Большое спасибо Дмитрий за совет. Дело в том, что мы написали свою систему тестирования, именно систему и ТС используется только для доступа к дереву объектов процесса и в будущем планируем полностью отказаться от него (я не хочу никого задеть, просто ТС не совсем удовлетворяет нашим требованиям), поэтому с exe файлом проекта хранить еще пустой проект ТС не очень хочется.
Во время запуска приложения, а именно когда создается экземпляр класса Connect запускается процесс ТС, и если при этом запустить отдельно ТС, то он выдаст ошибку что якобы одно из приложений уже запущено. Кроме того, заметил что практически все классы, которые предоставляет ТС доступны и в классе Connect, поэтому я предполагаю что сущесвует способ настройки проекта не из среды ТС.

Большое спасибо Дмитрий за совет. Дело в том, что мы написали свою систему тестирования, именно систему и ТС используется только для доступа к дереву объектов процесса и в будущем планируем полностью отказаться от него (я не хочу никого задеть, просто ТС не совсем удовлетворяет нашим требованиям), поэтому с exe файлом проекта хранить еще пустой проект ТС не очень хочется.
Во время запуска приложения, а именно когда создается экземпляр класса Connect запускается процесс ТС, и если при этом запустить отдельно ТС, то он выдаст ошибку что якобы одно из приложений уже запущено. Кроме того, заметил что практически все классы, которые предоставляет ТС доступны и в классе Connect, поэтому я предполагаю что сущесвует способ настройки проекта не из среды ТС.

Если не секрет, на чем написано тестируемая система и чем не устраивает ТС ?

Не устраивает по нескольким причинам:
- ТС предполагает наличие определенных навыков программирования. Это очень замечательно, если тестировщик - это тот же разработчик или был им когда-то. Но даже в этом случае, например язык «C#Script» требует немалой сноровки, т.к. мало чем похож на C# (сугубо личное мнение). В нашу компанию ТС приобретался исключительно для тестировщиков, но, к сожалению, их знаний для работы с этим продуктом не хватило, т.к. они очень далеки от программирования, да и к тому же они являются внедренцами, и постоянно приходится общаться с клиентами. Поэтому времени на изучение языка и основ программирования у них нет.
Но продукт ТС был уже куплен, да и не пропадать же добру)
Решили поступить следующим образом – написали на C# своё приложение, которое грубо говоря отфильтровывает из тестируемого проекта невидимые элементы выводя на экран только те, которые доступны пользователю, а в качестве методов предоставили только те которые возможно сделать с этим элементом имитируя работу мыши и клавиатуры, причем всё выводится на русском. И названия элементов, например тех же текстовых полей берется из рядом стоящего «лэйбла». Тестировщик оперирует только с видимыми элементами управления (ЭУ). В последствии снабдили такими методами которые проверяют после конкретных действий контрольные значения. Кроме того было добавлено немало проверок, и способов упрощения работы. В итоге создается некий сценарий, именно сценарий описывающий по некоторым уникальным признакам ЭУ и действие с ним, причем в нем же указывается будет ли вызвана новая форма или нет, и какой сценарий прикреплен к этому действию. Таким образом, получается, что скрипт формируется в RunTime режиме, и подстраивается под изменившуюся структуру формы. После прохождения теста формируется лог, в котором отлавливаются все вылеты, а также те логические ошибки, проверка которых была заложена в систему. Также всегда можно посмотреть схему связанных сценариев, при этом в них же можно увидеть кол-во ошибок (сухая цифра) после прохождения тестов, т.е в каком конкретном сценарии произошла ошибка. В них же можно увидеть то насколько актуальны сценарии, несмотря на то, что система устойчива к изменениям всё равно можно «испортить» тестируемый проект, так что сценарий окажется не пригодный. Актуальность оценивается из суммы коэффициентов покрытия (кол-во участвующих в тесте ЭУ по сравнению с общим количеством ЭУ), и коэффициента действительности (кол-во не найденных ЭУ на форме). На схеме можно задать интервалы коэффициента. Например, интервалы 0<30<60<100, попадая в определенный интервал блок сценария подсвечивается определенным цветом (зеленый, желтый и красный) и если сценариев очень много, то можно легко оценить - сколько из них не актуально и сколько нужно переделать. Также есть долгосрочный анализ исправления ошибок, там уже на графике можно увидеть, как исправляются ошибки и не появляются ли новые.
На данный момент нашли способы, как обойтись без ТС. Но переделать пока не решились.