An ABL Windows can be embedded in a .Net form, but is has some limitation. The most important is that the menu bar of the ABL Windows is not displayed (and the accelerator associated are not fired). We find that is not acceptable. We have thousands programs to rewrite with a new interface and we can't do it in one time. So we want to make it module by module with a mixity of new and old programmes without important modification on our old programmes. The limitation with the menu bar is for us a major problem, we thought that we could have a good mixity of ABL Windows and .Net forms, but it's not the case. We thought that this mixity was a great reason to choose OE 10.2 for our new UI, but now we ask ourselves why not choosing another language if we can't have perfect embedded ABL windows.
Thank you for any comments or suggestions.
If you want to keep the old menu bar why do you want to embed in the first place? You can just run the window as you used to and start a new window with the new UI and run them side by side in the same session. The only reasons to embed windows (as far as I can see) are:
- to use MDI (in which case you want the menu in the MDI container - that automatically means a new menu)
- to make a new form where a part of the form is reusing an old smartframe that has not been rewritten yet, you wouldn't expect a menu there either.
Even if (despite the above) you were to need to embed all windows in .NET forms, redefining the menu's would be a tiny task compared to choosing another language (where you would not only have to redefine your menu's but everything.)
PSC doesn't automatically translate menus at runtime to .NET because they want us to be able to choose what menu control we use (makes sense.)
I would appreciate a tool to assist in translating existing menu's to the infragistics .NET controls, but we can make that ourselves to (either at runtime running through the handles of the menus or by parsing the code, for example with proparse.)
That doesn't make the decision not to automatically translate menus unacceptable, it's a wise decision with indeed very significant disadvantages, but also with a very important advantage: we can choose the menu controls, we're not tied to PSC's decision of whats best. The product hasn't even been released and already people are suggesting various other controls over infragistics'.
An ABL Windows can be embedded in a .Net form, but is
has some limitation. The most important is that the
menu bar of the ABL Windows is not displayed (and the
accelerator associated are not fired). We find that
is not acceptable. We have thousands programs to
rewrite with a new interface and we can't do it in
one time. So we want to make it module by module with
a mixity of new and old programmes without important
modification on our old programmes. The limitation
with the menu bar is for us a major problem, we
thought that we could have a good mixity of ABL
Windows and .Net forms, but it's not the case. We
thought that this mixity was a great reason to choose
OE 10.2 for our new UI, but now we ask ourselves why
not choosing another language if we can't have
perfect embedded ABL windows.
Thank you for any comments or suggestions.
Have a look at this thread: There is a rough class that converts a window menubar into a .net equivalent. Maybe a good starting guide for you.
As a general thing, I see little point in embedding a window if the entire window is copied - why not simply run the old window ?
Thank you for the responses.
My goal is to have a new main window (.Net form), and from that window I simply want to run old ABL windows and new .Net forms. If I run my old ABL window (not embedded), the ABL window is independent. If I reduce the main window, the old window won't be reduced. But maybe I miss something.
If I can't have this behaviour, what advantage with OE 10.2 if I need to run ABL windows and I don't want to spend time to write a menu conversion for my ABL windows ? I could imagine to execute a Progress session with my old ABL windows from a new UI written in C#.
first of all, you can parent the ABL window to the .net form, so when you minimise the .net form the abl window is minimised as well. Have a look at the documentation.
Second of all, the menu conversion program has already been written for you. Have a look at the attachments in the thread I directed you to.
Third, "what advantage" ? you can use the ABL that you know, that very powerful ABL, with a UI that matches c#
Was there supposed to be a link or attachment in this post?
Beside this parenting like Julian suggested, the main advantage over writing a C# application running "side by side" with an ABL application, is that with 10.2A you can have the same effect in a single application.
And a single application has a number of advantages:
- Screens can cooperate / talk to each other
- An event modell between screens (yes OO has no native publish / subscribe yet, but there are handy ways to get around this)
- share session information (even global shared varialbes) and context
- share transactions, appserver connections
- share input blocking dialogs / prompts
- Reuse business logic components
- A good chance to rewrite ABL windows to .NET UIs - at least using cut & paste
- Enriching ABL windows using .NET Controls when choosing an approach that Julian described as embedding SmartFrames
Was there supposed to be a link or attachment in this
post?
Check this thread: http://www.psdn.com/library/thread.jspa?messageID=35267觃
(I must admit, I did not test the code yet, but I wrote my own routines that do the same stuff)
I was leaving it as an exercise to the reader to find the thread ...
Sorry, I did not intend to ruin the surprise.
Damn you Sir! Pistols at Dawn !
Earlier on in the presentations on this new capability, Shelley and others talked in terms of taking selected windows from an application and transforming these while leaving the rest of the application alone for the time being. The idea being that one would have minimal disruption and expense and yet would be able to jazz up key screens that would make a difference. If that fits your needs, I think that is still one of the possible approaches that one could take.
More recently we got this alternative notion of embedding existing ABL windows within a .NET form. There are some understandable limitations to this approach, notably having only the main window, but clearly it also presents the option of having a more unified appearance. The extra cost is that one has to do something in the new UI code to compensate for the missing bits. If your menus are pretty standard across the application, than they would come as a natural consequence of reinventing the "home" window. If they vary greatly, then you are probably going to have to do a lot more work to get the right menu on the right screen ... or going to have to rethink how those menus get presented.
If the embedding approach is more effort than you can afford right now, then I would go with the side-by-side approach.
I would like to make a small remark about the MDI interfaces everyone seems to want because they are now available: They are no magic bullet! There are situations where an MDI is desirable but more often they impose a disadvantage: No longer you can drag around your windows wherever you want. No longer you can easily make full use of a dual monitor setup. No longer is it possible to have one form on the left side of your screen, a browser in the middle and another on the right side of the screen.
When I was at school (only 4 years ago) I was even told `never to use' MDI because it was not user friendly. I disagree with my teachers about the never, but I do want to warn that it is often not a very productivity increasing idea to lock in your forms into a cage. Doesn't anyone else ever want to drag the editor out of Eclipse, doesn't anyone put the photoshop toolboxes on a second monitor when editing a photograph,...
Just a thought.
it's a great point to make. At a presentation I did recently, I warned people that "Just because you can, doesn't mean you should". There are plenty of ways of putting lipstick on a pig - but the end result is not very nice.
Take your time to speak to your users, prototype with them, think differently. We are not constrained any more by the UI - but with that power comes a heavy price. Make best use of the best components that suit the job, do not try to fit the job to the interface.
Message was edited by:
Julian Lyndon-Smith
Have you tried dual monitor support in Eclipse using a new workbench window? That's fully possible and I use it very often. Have you tried dragging around editor windows in Eclipse? Splitting the editor area? All fully possibly and for most actions the workbench remembers the users actions and restores them when you reopen a view or editor view.
With the combination of multi-window MDI and dockable panes, you can reach a very high level of user customizable screens. For many users this does a great job - not for all users.
The good thing is, we can use these capabilities as well. The Infragistics tabbed MDI manager and dockable pane manager (works in beta 2) offer the same UI capabilities as the Eclipse workbench.
You still need to add a lot of generic handling code around these managers.
Everything you do in your application screens (not the menus) is not directly affected by these measures. A form can a an MDI child but it does not have to be. A user control can sit on a Form or be docked as a pane.
I personally like the combination. Browser windows inside the MDI container. Detail windows opened separately - reminds me of Outlook.
To return to the embedding of ABL windows: That technique is the key to support these UI features in a 10.2A application. An ABL window can directly be embedded in an MDI Child Form or in a container control. That container control can be used in dockable panes or anywhere else on a Form. That gives us flexibility.
I personally don't miss the fact that we don't see the toolbars. Who'd like to have the ugly gray menus anyhow if you can have colorful menus (user customizable) for the same price?