OCX replacement for 64bit of the Microsoft ProgressBar Contr

Posted by PeterWokke on 20-Jun-2014 01:32

Dear all,

I have started the replacement of the OCX controls for 64bit. 

One of the OXC objects should be the Microsoft ProgressBar Control.

I cannot find a control between the list to chose from. Does someone has an idee where I can find a replacement for this ProgressBar OCX.

Kind regards,

Peter Wokke

All Replies

Posted by Mike Fechner on 20-Jun-2014 02:07

How many of your screens to use the Progress bar Control.
 
I more future proof solution might be to migrate those screens to GUI for .NET. Or use a mix of classic ABL GUI and GUI for .NET (Embedded Windows).
 
 
 
Von: PeterWokke [mailto:bounce-PeterWokke@community.progress.com]
Gesendet: Freitag, 20. Juni 2014 08:33
An: TU.OE.Development@community.progress.com
Betreff: [Technical Users - OE Development] OCX replacement for 64bit of the Microsoft ProgressBar Control
 
Thread created by PeterWokke

Dear all,

I have started the replacement of the OCX controls for 64bit. 

One of the OXC objects should be the Microsoft ProgressBar Control.

I cannot find a control between the list to chose from. Does someone has an idee where I can find a replacement for this ProgressBar OCX.

Kind regards,

Peter Wokke

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by PeterWokke on 20-Jun-2014 02:37

Mike, Thank you for your replay. We have used this ProgressBar just on a few places.

Beside the ProgressBar we use the TreeView a few times and WebBrowser object.

For those  there are OCX components available.

Our application is based on the adm2 smatObjects. To add .Net objects to a smartObject container is there a lot to adjust for this. Hope you can guide me on this.

Regards,

Peter Wokke  

Posted by Mike Fechner on 20-Jun-2014 05:39

Is the Progressbar located on a standard ADM2 window (which users might also use for data entry), or is it used on a small dialog itself?

In the first place, you should read on Embedded Windows as you need to embed the SmartWindow in a .NET Form before you can add .NET Controls to that Form (appearing to the User as if the .NET Controls as part of the Progress SmartWindow).

Going that route may be a bit heave just for a few screens using the Progressbar. But it opens the opportunity to use more .NET Controls in Progress Windows, like Ribbons, etc. as a general face lift

http://www.consultingwerk.de/typo3temp/pics/60a13820fb.png

I recommend you to read on the GUI for .NET Developer guide.

We’ve developed the WinKit tool for this purpose.

 

Posted by Jeff Ledbetter on 20-Jun-2014 09:45

Hi.

"We use the TreeView a few times and WebBrowser object. For those  there are OCX components available."

Which 64-bit treeview OCX control are you using?

Posted by PeterWokke on 23-Jun-2014 09:03

From the OpenEdge Installed .NET Controls I could implemet the following replacments for the OXC controles:

ProgressBar System.Windows.Forms

TreeView System.Windows.Forms

WebBrowser System.Windows.Forms

For a more future proof solution I can assume that a Progress 32bit client and a Progress 64bit client under Progress 11.3 can work with the same compiled run-time files. This way my customers can select there own client on the Window PC they still have.

Differently to using OCX controls where I have to make different versions for the same application.

Hope someone can confirm this statement.

Regards Peter Wokke

Posted by Mike Fechner on 23-Jun-2014 09:12

Hi Peter,

yes, your assumption is right.

OpenEdge 11.3 R-Code is compatible between 32 and 64 bit.

Most .NET Controls work fine on 32 bit and 64 bit workstations. It is however possible, that some .NET Assemblies are compiled only against certain processor architectures. But that’s pretty uncommon and something you can consider when buying the .NET Controls you integrate in your application.

The standard Microsoft WinForms controls and Infragistics/OpenEdge UltraControls are processor independent J and will work on 32 bit and 64 bit.

Posted by Jeff Ledbetter on 24-Jun-2014 17:53

So.. there is no replacement 64-bit OCX available? The only option is use the .NET UI?

Posted by Frank Meulblok on 25-Jun-2014 04:05

Well, there won't  be a direct replacement until Microsoft suddenly decides they'll port the common controls libraries to 64-bit after all. So either you go for .NET, or for some 3rd-party control which may or may not be easy to find, and which may or may not carry additional license fees.

I was able to dig up this: www.dbi-tech.com/ComponentPage_ctxMeter.aspx

But I have zero experience with that particular set of controls, so I can't offer a valid opinion wether they're a good replacement or not.

Posted by PeterWokke on 26-Jun-2014 06:04

First I would like to thank every one to add value to this subject.

Based on the information the best option is to implement .Net replacements.

This means that the current application need to be initiated with .Net capabilities.

The application is based on the smartObjects from the adm2.

The menu window is set by a treeview object that need to be replaced anyway so if I rebuild that as a ABL .Net window than the current program windows can be launched from this new menu window. And new programs based on .Net components can be added to the menu and the application after.

Who has experience to merge a adm2 application with a ABL .Net GUI.

Posted by tbergman on 26-Jun-2014 06:42

If the only OCX you’re stuck on is the progress bar, have you considered making your own from one or more Progress rectangles?. It’s easy enough to set the width of the rectangle to any size you want dynamically to emulate a progress Bar.
 
Tom Bergman
 
[collapse]
From: PeterWokke [mailto:bounce-PeterWokke@community.progress.com]
Sent: Thursday, June 26, 2014 7:05 AM
To: TU.OE.Development@community.progress.com
Subject: RE: [Technical Users - OE Development] OCX replacement for 64bit of the Microsoft ProgressBar Control
 
Reply by PeterWokke

First I would like to thank every one to add value to this subject.

Based on the information the best option is to implement .Net replacements.

This means that the current application need to be initiated with .Net capabilities.

The application is based on the smartObjects from the adm2.

The menu window is set by a treeview object that need to be replaced anyway so if I rebuild that as a ABL .Net window than the current program windows can be launched from this new menu window. And new programs based on .Net components can be added to the menu and the application after.

Who has experience to merge a adm2 application with a ABL .Net GUI.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Mike Fechner on 26-Jun-2014 07:00

“Who has experience to merge a adm2 application with a ABL .Net GUI.”

We supported a couple of ADM2 customers with our WinKit already.

Posted by Thomas Mercer-Hursh on 26-Jun-2014 09:47

I haven't used it, but based on a presentation of Mike's I attended, WinKit sure looks like the easy way to go about this ... as opposed to the hard way, if you know what I mean, where the hardness comes mostly from poking in the dark to figure out what to do.

Posted by Darren Parr on 10-Jul-2014 10:44

Hi

This topic is currently hot with us too. We have several ADM2 viewers with treeview, calendar controls from v6 of the microsoft common controls. Am I correct is stating that someone is saying its possible to drop a .net control onto an embedded window. This is something I thought was impossible at the moment...

Mike's example above seems to have an embedded window at he same level as his ribbon. I haven't seen a .net control inside an embedded window as of yet.

Thanks

Darren

Posted by Mike Fechner on 10-Jul-2014 10:52

You can’t drop a .NET Control into an ABL Widgets. But once you embed an ABL Window in a .NET Form, the ABL Window can partially be overlaid (in that .NET Form) with any .NET Control.

The user won’t see the difference.

http://www.consultingwerk.de/typo3temp/pics/b64f733b49.png

.NET Ribbon, a few ABL Frames, UltraTabFolder and UltraGrid. All put together using Embedded Windows.

 

Posted by Darren Parr on 10-Jul-2014 11:22

OK. Sounds great. I might give this a go.

This thread is closed