Hi All,
This is probably something basic but I just need a hand with starting it off. We used to have a ABL screen with a TreeView OCX used in progress OE 10.1. We have recently upgrade to 11.5 64bit and therefore can no longer use the OCX as there is no 64 bit as far as I'm aware. I'm trying to replace it with a .Net TreeView but I'm not sure where to start.
I've managed to replace the Crystal Viewer successfully but that was mainly due to example codes that were already available in the KB (mainly http://knowledgebase.progress.com/articles/Article/000056268?q=.net+crystal&fs=Search&pn=1&l=en_US). That was also simpler to do because the form only had the crystal viewer on it. The current screen I'm working on has a number of other ABL controls and widgets that needs to remain along with the .Net Tree View. Is this possible to do?
I tried copying what I did for the crystal viewer by doing something like the below:
def var FormObjectRef as class Progress.Windows.Form NO-UNDO.
def var CFTreeView as class System.Windows.Forms.TreeView No-undo.
FormObjectRef = NEW Progress.Windows.Form().
CFTreeView = NEW System.Windows.Forms.TreeView().
FormObjectRef:Controls:Add(CFTreeView).
WAIT-FOR FormObjectRef:ShowDialog().
This works for displaying it stand-alone but how can I incorporate it into an existing .w file?
Hopefully this makes sense. Thanks in advance!
Hi,
There are only limited options for mixing and matching .NET and ABL UIs. You can't add a .NET UI control to a .W for example, nor can you add an ABL widget to a .NET form directly. Your example works because it is all .NET; you could open it *from* a .W but not *in* a .W.
You could rebuild the original .W as an ABL .NET form, replacing the ABL widgets with their .NET equivalents.
Alternatively you could potentially create a new form with the .NET TreeView and then embed the original .W into the form to preserve much of the original functionality. I think it should be possible to have the .NET TreeView events call procedures in the embedded .W.
The GUI for .NET Programming manual has more information about embedding windows into forms.
The 2nd option Rob mentioned - a form with a .NET treeview and the original .w frame embedded in the form - probably won't work as you expect. i.e., I expect there will be problems tabbing between the treeview and the ABL controls. You can certainly try it as a first pass. But I think having a purely .NET form is likely to be your best bet.
The thing which is not possible is to embed .NET Controls into classic ABL GUI (.w files).
However you can embed the whole window (all or just the single one) into a .NET Form using the Embedded Windows which is documented in GUI for .NET documentation. Technically the classic ABL Window will be realized in a WindowContainer .NET Control which is put on a .NET Form. This concept of mix and match is not uncommon in the .NET world: Microsoft offers an ElementHost that allows to embed WBF into WinForms and a similar host control to embed WinForms into WPF. So the WindowContainer is Progress' response to the need to use classic ABL GUI with .NET.
Once the ABL window is embedded into the WindowContainer and then into a .NET Form you can "decorate" the classic ABL window with .NET Controls (around or overlaying). Look at this screenshot:
[View:http://www.consultingwerk.de/typo3temp/pics/b64f733b49.png:0:0]
That's an ABL window embedded into .NET using the Infragistics (2009 in this case) ribbon, the Infragistics UltraTab Control and an UltarGrid which
a) hide the ABL browse by overlaying it
b) uses the browsers query to show the list of order lines
We've developed the WinKit toolkit to simplify the use of embedded ABL windows: www.consultingwerk.de/winkit
Hi,
There are only limited options for mixing and matching .NET and ABL UIs. You can't add a .NET UI control to a .W for example, nor can you add an ABL widget to a .NET form directly. Your example works because it is all .NET; you could open it *from* a .W but not *in* a .W.
You could rebuild the original .W as an ABL .NET form, replacing the ABL widgets with their .NET equivalents.
Alternatively you could potentially create a new form with the .NET TreeView and then embed the original .W into the form to preserve much of the original functionality. I think it should be possible to have the .NET TreeView events call procedures in the embedded .W.
The GUI for .NET Programming manual has more information about embedding windows into forms.
The 2nd option Rob mentioned - a form with a .NET treeview and the original .w frame embedded in the form - probably won't work as you expect. i.e., I expect there will be problems tabbing between the treeview and the ABL controls. You can certainly try it as a first pass. But I think having a purely .NET form is likely to be your best bet.
Thanks for your replies.
The issue I have is that the .w which currently has the OCX is a browse .w file that is embedded into another frame .w which is a complex screen that has multiple folders/tabs calling different files. If I'm to use the .NET treeview, then do I need to embed the browse .w into a new .Net form which is then embedded into the frame .w or is that not possible and I would need to replace the entire frame .w with the .Net form? If the latter then it is probably not feasible as there is just too much to change.
Is there another option that I can go with? I had a look and found Pure4GLTV which is basically a clone of the MS Treeview OCX but it seems that it's built using adm2 and we're currently using adm1 so that doesn't seem feasible.
Also I'm not 100% sure that I can no longer still use the MS Treeview OCX, I simply assumed so after reading this post. However, when I open up the file in 64bit version 11.5 app builder, it gives me the error 'Specified ActiveX control is not registered or the .ocx file was moved from where it was registered'. But I can still see a CTreeview control (C:\windows\system32\dmocx.dll) from the list of OCX controls and once added to my browse .w file, it compiles without any issues. It is only when running, I'm getting errors saying that the methods are not available, i.e. 'Invalid component-handle referenced while processing method/statement:Notes', for a simple call such as chCFTreeView:TreeView:Nodes:Clear.
The thing which is not possible is to embed .NET Controls into classic ABL GUI (.w files).
However you can embed the whole window (all or just the single one) into a .NET Form using the Embedded Windows which is documented in GUI for .NET documentation. Technically the classic ABL Window will be realized in a WindowContainer .NET Control which is put on a .NET Form. This concept of mix and match is not uncommon in the .NET world: Microsoft offers an ElementHost that allows to embed WBF into WinForms and a similar host control to embed WinForms into WPF. So the WindowContainer is Progress' response to the need to use classic ABL GUI with .NET.
Once the ABL window is embedded into the WindowContainer and then into a .NET Form you can "decorate" the classic ABL window with .NET Controls (around or overlaying). Look at this screenshot:
[View:http://www.consultingwerk.de/typo3temp/pics/b64f733b49.png:0:0]
That's an ABL window embedded into .NET using the Infragistics (2009 in this case) ribbon, the Infragistics UltraTab Control and an UltarGrid which
a) hide the ABL browse by overlaying it
b) uses the browsers query to show the list of order lines
We've developed the WinKit toolkit to simplify the use of embedded ABL windows: www.consultingwerk.de/winkit
I'm reading conflicting reports as to whether the treeview can work on 64-bit or not.
Did you try this:
C:\WINDOWS\sysWOW64\regsvr32.exe C:\WINDOWS\sysWOW64\MSCOMCTL.OCX
I think I have tried this in the past to no avail. I just tried it again then and I'm getting this error
When I try to add it to the OCX list in app builder, it gives me the error 'Registration of control failed. Please make another selection'.
I don't think I can get the mscomctl working with 64 bit and it's too much work to convert the whole main frame to a .Net just for the TreeView so we'll look at replacing it with a browse instead.
Thanks for everyone's help!
Thanks Mike for your reply. It looks good but is too much work at the moment for us to just to be able to replace a treeview. If all else fails, we might just replace it with a browse or something for now... but it's definitely something we'll be looking into when we overhaul our current UI
I just want to mention that the error "The module ... was loaded but the call to DllRegisterServer failed..." usually comes when the DOS Command has not been opened in "elevated" mode (aka "Run as administrator").