К основному контенту

DialogBox vs. EmbeddedView. Round 2

Проблема DialogBox с EmbeddedView в нем разрешена, пожалуй до конца. Второй раунд экспериментов удался.


Сразу хотел бы выразить благодарность Павлу Алешкевичу, что помог разобраться в проблеме и сподвиг на детальный разбор

Если кратко, то в первой части "эпопеи" я столкнулся с проблемой, что, если на форме, вызываемой в DialogBox присутствует EmbeddedView (и кнопки в DialogBox кастомизированы), то обновление подложки не происходит.

Провел более детальный эксперимент.
На форме были сделаны 4 кнопки:
1. На LotusScript получает доступ к EmbView и выделенному в ней документу, пишет в подложку UNID выделенного документа, вызывает закрытие DialogBox как кнопка ОК.
2. На LotusScript проставляет в подложку флаг и вызывает закрытие DialogBox как кнопка ОК.
3. На @-Формулах проставляет флаг в подложку и вызывает закрытие DialogBox как кнопка ОК.
4. Отмена

Итоги работы каждой:
1. Все идет отлично до вызова  NotesUIWorkspace.RefreshParentNote
После некоторых мучений мозга в него приходит озарение, что при получении EmbView фокус переходит во вью где, как раз и идет попытка вызова RefreshParentNote, возвращающий: Notes Error - Specified command is not available from the workspace.
После того как фокус был возвращен туда, откуда начал свой путь и переполучен NotesUIWorkspace, операция завершилась успешно и подложка была обновлена.

2. Кнопка отработала с первого раза в соотв. с ожиданиями - подложка обновлена.

3. Не сработало...быть может @-ки получают фокус на EmbView. Но факт остается фактом: код в кнопке (остался неизменным с прошлого раунда) не отрабатывает, если в DialogBox есть EmbView.

Правильные выводы:
1. Проводить более полные эксперименты для начала.
2. Не терять логику. Очевидно, что она была потеряна, когда получал фокус на View и не вернул его.

Вот так :) Все нормально, панику отставить!)

Контакты:


Комментарии

Популярные сообщения из этого блога

Занимательные алгоритмы. Поиск цикла в односвязном списке

И снова про тараканов, которые иногда возникают в голове. Как-то раз, засыпая, я задумался на курьезными задачками из своей сферы деятельности (Lotus Notes), которые можно было бы задать на собеседовании, плавно перешел к воспоминаниям о своих первых собеседования, когда опыта работы еще не было. Опыт самих собеседований у меня не велик а места, где задавались действительно интересные задачи (а не задачки типа: написать сортировку массива любым известным способом) вообще равны одному - это ABBYY. Как минимум одна задачка в списке на знание и понимание классических алгоритмов, описанных в книге Дональда Кнута -  Искусство программирования .

Unit-testing object validation when validator has DI

Summary Unit test object validation when validator(s) has a dependency. For instance, we have some custom field and cross-field validators. Want to test their combination. Additionally some of validators have dependencies, injected through constructor or setters. You're not using property injection, right? Shortcut If you are just searching for an answer, here's the fast way: Declare CustomConstraintValidatorFactory that implements javax.validation.ConstraintValidatorFactory Override getInstance method and on facing your constraint validator class instantiate it Otherwise delegate validator construction to org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorFactoryImpl Build validator factory and provide it your CustomConstraintValidatorFactory Build validator, using that factory... Go to demo project on GitHub for details:  https://github.com/MrArtemAA/blog-demos/blob/master/test-validator-with-injection/src/test/java/ru/artemaa/...

Use @SpringBootTest for validator's unit test and be fast enough

This a continuation of the post: https://live-scripts.blogspot.com/2020/02/unit-testing-object-validation-with-di-in-validator.html#more . Last time we talked about testing a validator, which has a dependency. Using pure @SpringBootTest turned out to be too slow. So I showed a "trick" to override the validator's factory in order to inject the dependant object. This reduced test run time. I promised to show a way to use @SpringBootTest , autowiring, and still be quick enough.