on 09-19-2014 7:25 AM
Hi,
I've got an application written in PB 10.5 using the Kodigo framework. I would like to migrate it to the latest version of PB, but part of the project includes a COM component which I can't migrate because support for COM components has been dropped. The COM component includes a NVO which (among other things) opens an input window which is also used elsewhere in the application. The COM component is called from a VB.Net Word Addin. What are my options for updating this component to the latest version? Do I need to create a .Net Component? Is there a way to migrate a COM component to .Net?
Thanks.
Thanks Chris, I didn't realize you could do that. But sorry, it doesn't help me in this case. I'm talking about a Component Object Model component.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you need to enhance the COM component's functionality with features from a newer PB? I just keep an older copy of PB around for my COM component, although I've never bothered recompiling it. I just distribute the older PB DLLs to support it, along with the new PB DLLs to support the main app.
This may or may not work for you. Just thought I'd throw it out there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Terry,
The COM component shares quite a bit of code with our main application which we were hoping to migrate to a newer version of Powerbuilder. We probably don't need the newer PB features yet but we may in the future. The main reason I wanted to try and migrate the component to a newer version is because I have a nasty intermittent bug that I can't track down and I wanted to see if it was fixed by building in a newer version of PB. Occasionally the COM object just seems to disappear from memory when a datastore is retrieved. I've tried to use try catch blocks but for some reason I can't trap the error. Very rarely and for some users only it seems to get to a certain line of code and then the COM object just disappears from memory.
... mmmh.... a serial port component object model...or just an error in the speed reading?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
but part of the project includes a COM component which I can't migrate because support for COM components has been dropped.
Is this COM component ActiveX or is it accessed via OLE Automation. What does it do?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bruce,
I don't think it is either really. It is used in a .Net application using the COM Interop layer. The object is called from Word via a Word Addin written in VB.Net. It's part of a document management system which among other things retrieves document metadata and uploads and downloads documents. It also displays a window that allows the user to enter metadata about the document. The code for retrieving the data, uploading and downloading the documents and the metadata input window are all shared with the main application.
Yes, that's correct. It is a COM component created from Powerbuilder that is mainly used in a .Net application. (It is also used in another older Win 32 application but I can work around that).
The windows that are displayed from the COM component are from our main Win 32 application and are written using the Kodigo framework which uses a PBNI extension called Canvas.pbx. I thought because they relied on a PBNI extension that I couldn't create a .Net assembly, but I'd be happy to be told otherwise.
I've had a brief look at creating a .Net assembly, but I'm a bit lost. Do I need to create that in PB.Net or can I use PB Classic? I'm a bit confused about how PB.Net and PB Classic work together. I've only started looking at PB.Net last week, but are their any tutorials on creating .Net assemblies?
The .Net assembly target in PB Classic only creates assemblies based on non-visual objects. You could use that if you wanted to package up the business logic that PowerBuilder is currently handling, without displaying visual components. (For that matter, you *may* be able to pop open a PowerBuilder window from the non-visual component, but I haven't tried it).
The .Net assembly target in PB.Net allows you to do them based on non-visual objects (subject to the same limitations above) or for visual components. The visual components would be in WPF though, so the PBNI extension that Kodigo is using would definately not work. However, WPF does give you graphical capabilities that might be able to replace what you were using that extension to do. The question at that point is whether the .Net application you are trying to include this in is also WPF.
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.