AnyScreen (форсировали Неман Бонапартовы войска) - хроника войны

[Губин Игорь]

Откуда это известно?

Интерфейс на кларионе...

[finsoftrz]

Как раз на подходе заказ на небольшое автономное приложение с доступом из веба. На php делать неохота, трудоемко, а к ntws пока душа не лежит. Остается, похоже, anyscreen.

Сегодня посовещались, решено все же ntws потестить на этом приложении. Смысл в том, что само приложение небольшое и автономное (из серии service desk), а одновременно сидеть в нем будут примерно 40-50 человек. С anyscreen поддерживать такое количество подключений все таки процесс, учитывая нюансы с коннектом и реконнектом. Ntws, работающее как один экземпляр приложения в режиме запросов, в данном случае выглядит более предпочтительно, хотя разработка в нем достаточно нетривиальна при отсутствии опыта и наработок. Заодно на практике можно будет прочувствовать нюансы. Небольшое приложение на anyscreen особых проблем не вызывает, несколько месяцев не было обращений, но там и пользователей по пальцам руки посчитать, которые работают непродолжительное время и не каждый день.

[finsoftrz]

Некоторые интересные обсуждения были в официальных группах. Оставлю здесь без перевода.

Писал Jim из Seacoast Computer по поводу опыта использования thin@ и anyscreen.

We have been using Thin@ since version 2.x approximately 16-years ago
when we deployed an application to approximately 60 municipalities for
welfare management. The application was upgraded to Thin@ 3.x when it
was released and has continued to operate since then. We'll upgrade to
AnyScreen in the next year. It has been hosted in various locations
including our data center and AWS.

Leveraging what we had learned from that application, we deployed a full
municipal finance and revenue suite using Thin@ 3.x approximately six
years ago. This was then converted to AnyScreen shortly after it was
released.

The transition from Thin@ 2.x to 3.x and from Thin@ 3.x to AnyScreen
were relatively painless. There were a few things related to moving
from the Win Client to HTML Client and syntax changes from RIS to
AnyScreen, but these were minor.

For a limited number of our clients we still support local Windows
versions of these applications, but they use the same code with
conditional statements to allow for local and AnyScreen operation.

We use PostgreSQL database servers and currently have a four application
servers and three database servers running in our environment supporting
about 110 municipalities with two to fifteen users per municipality.
Fewer servers could be used based on the current performance profile,
but we do this to facilitate upgrades and for redundancy.

I have used multiple development environments in the past (dBase,
FoxBase, DataFlex, Win/WebDev, etc.) and can't imagine doing what we
have done with Clarion and AnyScreen in any other environment as well as
supporting as many users so easily.

Our clients really enjoy the windows-like look and feel that AnyScreen
provides along with the other features we have been able to provide.

Marko has provided input along the way when we needed it, but other than
some minor things this just works.

Happy to share any additional information anyone might want.

Best regards,
Jim
Seacoast Computer


===========================================
Hi Kelvin,

I have not tried running our applications (executable) from another
location or server. We do have some shared storage that is accessed
within the application (two application servers point to a shared
location for stored documents via a mapped drive) and this has worked
reliably.

One thing we found is that the user that will be used for AnyScreen
services should be the user that is used to install AnyScreen and any
other files, folders, etc. the applications will access. So the first
thing we do when setting up a new server is to create a new user (an
administrator) that will be used to start the AnyScreen services, then
we do the AnyScreen, Microsoft Office, printer, fonts, etc.
installations logged in as this user. (This is assuming you will not be
using the default administrator account to fun the AnyScreen services.)

Anti-virus/malware software has caused us some issues in the past with
realtime scanning. This seemed to cause the applications to hang
intermittently and some latency when the users launched an application.
We disable realtime scanning and run a nightly scan.

Thank you,
Jim

======================================================
Hi Peter,

Without knowing what you are specifically referring to - in general our
users do not see any AS generated messages or HTML pages.

Since our applications are multi-tenant, we use the AS login to
determine which database the user has access to and then SecWin for
application security.

The user is given a URL that logs directly into the application, rather
than the generic AS screen.

On (a proper) exit from our application we redirect the user to a static
HTML page we created that requests them to close the browse tab.

Or the users just closes the tab/browser and then the AS timeout takes
care of closing the application. This can take a while depending on the
timeout setting in AS, but has not appeared to cause us any problems.

Happy to try and help more if there are specifics.

Thank you,
Jim

[finsoftrz]

В другой теме Брюс Джонсон пытался "оправдываться" по NTWS, в том числе по сравнению с anyscreen.

NetTalk is a framework, and template set for building a scalable,
multi-user, web server. The architecture of that is different to the
architecture for a desktop app. So there's no way to take a desktop
procedure (with UI) and "convert" it to NetTalk. All the embed code
would be different for starters, but equally so would many other things.

It doesn't take long to create new browses and forms in NetTalk (mostly
because there's no screen to design) but it certainly is not a "one
click" solution.

For one-click solutions I recommend AnyScreen. That allows your program
to run "as is" on the server, and provides an interface to that program
on the client. It isn't as scalable as NetTalk (because each user is
consuming Ram and CPU) but that's the trade-off between a one-click
conversion and "native web" architectures.
...

Again, this is by design. In the DOS days the screen-formater was a big
deal, and a major productivity enhancer. Naturally it feels like the
Window Designer in desktop apps is inevitable. All programming
environments of the 90's used this approach.

The web however has a completely different approach. It separated the
"functionality" from the "presentation". In other words HTML/JavaScript
(the functionality) is separate to CSS (the presentation).

This "global" (rather than procedure - local) approach to layout, and
design, and look, makes programming much faster. It's faster to build,
and importantly, faster to change. Tasks which are hard in Desktop apps
(or at least tedious) are trivial in web apps, precisely *because*
there's no visual designer.

So it's faster to create a browse, or form, in NetTalk because you spend
your time on "what you want the procedure to do" and not on "what does
the procedure look like". Fundamentally the overall look of the program
is done at the *end* of the process, not the beginning.

I understand this is different to what you are used to. I don't expect
this argument to convince you; it certainly takes time to adapt to a
different way of doing things. All I can say, is that once you've done
it a bit you'll understand why going back to a desktop app is sooo
painfully slow.
...
From the user point of view, the web is a different platform to
desktop. The desktop hardware tends to be the same. Keyboard, mouse,
13"+ screen. For the web the hardware is obviously more varied (from 4"
to 21" screens), with or without mouse or keyboard.

Even the natural interactions with a desktop and web app are different.
On the web scrolling-down is a thing. (It's possible to do this in
desktop, but I've never seen it done, and it would be confusing there.)

When the focus is on mobile, the UI design tends to be "task driven",
not "data driven" as desktop apps generally are.

So, for me, the goal is not to make "a desktop app in the browser".
(Again, AnyScreen is a good approach if you want to do that.) Rather the
goal has been to see the web as a different platform, and then code
towards the strengths, and expectations of that platform.
...

From the programming point of view, I prefer things to move forward
that make me faster and more productive. But I understand that as we
grow older we tend not to want to learn "new things". And there's
certainly a lot of learning to do when targeting a new platform and
embracing what it can do.
...

Excellent! AnyScreen exists to fill the space exactly as you have
described it. You evaluated the choices and made a decision that's right
for you. Nothing wrong with that at all.

Which I guess speaks to Kelvin's original question in this thread. I'm
not sure what *more* he's looking for that doesn't already exist. I'm
sure there's something specific he has in mind, but so far I'm not sure
what that is.
...

No and Yes.

No, because there are no WYSIWYG features when you program the
application. You just simply "don't worry about that". Rather you focus
on the work-flow and functionality to begin with. There will never be a
WYSIWYG designer in a NetTalk app because that would be a step
backwards, not forwards.

Yes in the sense that you do of course have complete control over where
everything is positioned, and what it looks like. This is done at
runtime, by editing the CSS in the browser, seeing the effect, and then
adjusting the rules. Most changes are "global", but you can also do
local, and hyper-local ones as well.

This is a different pattern to desktop - where you do all your visual
design first, and locally. The "visual" aspect is still there, it's just
done differently, in a different place at a different time.

And again, it takes time and effort to adjust to that.

=============================

Probably not (although I can't say what "works for you"

"What You See Is What You Get" is a very specific concept. The clue is
there in the name. You place everything on a defined Cartesian plane -
every specified with xpos, ypos, width and height. This maps well to a
screen system which draws that plane - like Clarion's window editor.
Since the Clarion WINDOW structure is also a Cartesian plane the
approach maps one-to-one. (Let's call this layout "absolute").

The primary advantage with this approach is that you have a lot of
control, but in a "primitive" way. You put this button over here, you
make that list this width, and so on. You describe the window in
absolute positioning.

There are of course lots of disadvantages with this approach. It's a lot
of labor (but basically "unskilled", so easy, labor) and there's no
concept of "correctness" except your eye. There's no relationship
between controls, there's no indication of how the screen can be resized
and so on. (There's a resize template that allows you to start
specifying rules, and that adds even more work.)

If you have 1000 screens in your app, and you decide to change an icon,
or the window font, or pretty much anything, it's a lot of work.
Naturally you don't do that, because, well, it's a lot of work. So most
apps look "old" most of the time.

And yes, your customers have a targeted monitor size - remember endless
discussions of whether 1024 x 768 was still the minimum - of 1280 x 1024
was ok, and so on?

HTML was designed from day one to work on multiple platforms. There was
no guarantee of the screen size, and indeed no guarantee it was even a
graphical screen. So at the very fundamental level the way an HTML
document is displayed is "self relative" not "absolute". [1]

Since the page is not a Cartesian plane to begin with, the whole concept
of "WYSIWYG" is gone because fundamentally "What you see" on one
display, is absolutely not "What you get" on all displays.

Some editors have tried to reconcile these differences - either by
basically bastardizing the CSS so everything is "positioned absolutely"
or by putting in extra things like whitespace and so on to try and mimic
the Cartesian plane.

The result is always less than satisfactory because it's the wrong tool
for the job.

That's not to say you don't get "visual" editors. I use BlueGriffon for
writing my docs. These allow me to see the page as I go - but of course
it's not necessarily what the end user will see. It gives you access to
the result, but also access to the source. I write the text in the
"Wysiwyg" mode, but I manage the layout, and features, in the "Source" mode.

This sort of editor though is not useful for "apps". It's for text
documents. For apps you're wanting an absolute layout of lots of
controls, designed to fit a *very* specific screen size. That's such a
niche, and the end result such ugly code, that basically nobody bothers
to make a editor to do that. (Well, I guess someone does, but it's not
integrated with the Clarion IDE.)

Indeed the fact you've not been able to find one that "works for you"
probably tells you the problem is less the editor, and more "you". (I
don't mean that in a harsh way, but more as a fundamental
misunderstanding on your side.) Once you understand the nature of
"relative layout", you better understand why WYSIWYG isn't a good fit.

Which is not to say you don't have control. You absolutly can make a
page with fixed position to all the controls etc. It's just that it's
done with CSS.

[1] as it happens you can layout your document using absolute
positioning - it's a CSS setting. But it's typically only used for a
small minority of controls, and it's not typically something for the
"whole page".

Cheers
Bruce

[finsoftrz]

Начали работу с небольшим приложением под смартфоны. Само приложение очень простое. Основное это то, что оно предназначено для подключения со смартфонов к определенному разделу большой настольной системы. Словарь и app с декларациями базы данных и слоем функций для работы с ней просто копируется из большой системы. Библиотека системных функций (фреймворк) включает часть аналогичной библиотеки для большой системы с адаптированными к anyscreen диалоговыми окнами. Из этих окон используются всего несколько в данном проекте. Сама прикладная часть это одна dll и exe. Раскладка по размерам получается такой.
dlls рантайма ~6МБ
dll заглавная ~6МБ
dll фреймворк ~4.5МБ
dll проекта ~350кб
exe проекта ~50кб

Если верить, что винда загружает в оперативную память одну физическую копию dll, а приложения взаимодействуют с ней через таблицу виртуальных адресов, как пишут, то затраты ресурсов на запуск множества экземпляров такого приложения мизерные. Больше всего отъедает кларионовский менеджер памяти по мере работы приложения. Данное приложение SDI и большие объемы данных не молотит, по наблюдениям, отъедается памяти в диапазоне 2-5МБ.

Авторизация одноуровневая в anyscreen, авторизация в самом приложении автоматическая по имени пользователя в anyscreen. База данных btrieve. На андроиде приложение работает хорошо, проблем пока не замечено. На айфонах в списках не выделяются строки при нажатии на них и не срабатывает двойной удар пальцем. Первое не особо принципиально, второе решили установкой вызова контекстного меню длинным нажатием в параметрах anyscreen. Разворот экрана смартфона отрабатывается.

Параллельно с теми же данными работает основная настольная система на сервере, а также настольное приложение в магазинах, подключающее к серверу через ip драйвер.

Одна из веток приложения (отметка выполнения заявок) выглядит так.

[Губин Игорь]

Борьба продолжается...

После того, как во всех манифестах ip-адрес сервера был исправлен на доменное имя ситуация с восстановлением после выхода "щелчком по закладке" улучшилась, но не до конца. Окончательным решением, ну кто бы мог подумать , стал полный запрет касперскому следить за сайтом.

[finsoftrz]

Поскольку вопрос с ресайзером повис, то ли будет, то ли нет, можно такое решение предложить. Небольшой контрол шаблон, состоящий из 5 кнопок. Изначально видна только средняя.

После нажатия на нее появляются еще 4 для увеличения и уменьшения высоты/ширины окна. При повторном нажатии скрываются. Доступ только если приложение в режиме anyscreen. Drag/drop лучше, конечно, но другого в голову не приходит.

[Губин Игорь]

Поскольку вопрос с ресайзером повис, то ли будет, то ли нет, можно такое решение предложить. Небольшой контрол шаблон, состоящий из 5 кнопок. Изначально видна только средняя.

Идея интересная. Надо, действительно, решить эту проблему. Но я попробую пойти иначе, введением постоянного коэффициента масштабирования для всех окон и через меню.

У предложенного решения есть один маленький недостаток - что делать, если вдруг размер экрана уменьшился и заветная кнопка убежала за его пределы?! Можно, конечно, подвигать окно в поисках оной, но это не очень красивое решение.

[Игорь Столяров]

если вдруг размер экрана уменьшился и заветная кнопка убежала за его пределы?!

В таких случаях должен быть "План Б" для восстановления размеров и расположения окна по умолчанию:
- HOTKEY
- Открытие окна при нажатой кнопе CTRL или ALT.

[finsoftrz]

Само окно двигать можно. Я эту кнопку не хотел в верхнем правом углу размещать, она рядом с содержимым. Ресайз в основном таблиц касается. Все остальные контролы я специально перенёс в верхнюю левую часть окна, в том числе кнопки сохранить и закрыть в формах. Описанное решение для ресайза не претендует на красоту. Это вообще не удобно, жамкать на кнопки вместо растягивая окна мышью. Но хоть так, окна с таблицами, содержимое которых обрезается по горизонтали, настраивают я пользователем один раз. Я пробовал ещё открывать окна в максимизированном режиме. Это рабочий вариант, но не очень нравится.

[Губин Игорь]

В таких случаях должен быть "План Б" для восстановления размеров и расположения окна по умолчанию:
- HOTKEY
- Открытие окна при нажатой кнопе CTRL или ALT.

Не следует множить сущее без необходимости

[finsoftrz]

Общий коэффициент масштабирования можно устанавливать для сайта в броузере.

[Губин Игорь]

Общий коэффициент масштабирования можно устанавливать для сайта в броузере.

Код: Выделить всё

<meta name="viewport" content="width=device-width, initial-scale=1" />

Буду пробовать...

[finsoftrz]

Ещё идея есть автоматически стартовать во фрейме окно в максимизированном режиме и заблокировать его закрытие. В левой части его вывести меню в виде дерева или ещё как. Нечто подобное, как Марко показывал при рассказе про ресайзер. Вариант с одной кнопкой это для мобильных устройств с маленьким экраном. Для обычных офисных приложений не очень удобно.

[finsoftrz]

Аналогично ресайзу окна можно сделать и сплиттер. Ниже скриншот с ресайзером, сплиттером и вертикальным меню.
Как работает: https://finsoftrz.ru/mp4_tmp/anyscr_menuV.mp4