hexagon logo

Got Visual Studio and the Interop.PCDLRN.dll... Now what?

As I upgraded one CMM to Windows 7 64-bit, my small VBS helpers died in the process (still kickin' butt on XP though).
So, I have begun re-coding them in Visual Studio 2010 (I think). I have gotten so far in the coding where I need to connect to PC-DMIS and start interfacing with it. Now, I managed to find the DLL that is supposed to expose some interfaces and methods and I have successfully added it to my project.

Then what? How do I use the DLL to connect to PC-DMIS and expose the PartPrograms collection for instance?

Oh, I am using C# for this...

Any and all input, examples or suggestions are VERY welcome!

TIA!
  • That's my take on it DaSalo - all I need it for is PC-Dmis related stuff and for that it's easy and works well!


    When I worked for Hex we were contacted by IPI Solutions (who've made VisualFAIR) who were interested in PC-Dmis integration.

    One of their developers (proper C programmer) came to see me, and initially he scoffed (in a nice way) at the fact I was using VB.

    It took me about 5 mins to write a rough script which exported results into excel. He was shocked I could do it so quickly in such a few lines of code. He said it would probably take him about half a day just to hook into excel. No doubt his solution would have been quicker, use less memory and be robust and containing proper error checking and handling etc, but as a tool for COM automation, VB is great!
  • In the earlier VB days, you had to have the Visual Basic runtime-modules installed that handled the VB interpretation in order for your program to "work". Also, the VB created programs were slow compared to C/C++.

    For PC-DMIS specific stuff, pick your preferred weapon of choice, be it VB or whatever. As long as it does what you need it to do, I see no reason to switch to any other language. For me, I picked C# for the variety of supported platforms (I do a lot of other stuff, I tinker and create custom programs to help me (us) in our day-to-day activities). So, I reckoned I'd gain more from going the C# route.

    My personal preference, nothing else.
  • In the earlier VB days, you had to have the Visual Basic runtime-modules installed that handled the VB interpretation in order for your program to "work".


    And today you need the .NET libraries installed, both for C# and vb.NET. But PC-DMIS needs that (.NET) too, so you don't see the problem...

    And continuing on that track - as C# needs .NET, how can it be useful in any other environment than Windows? Have I missed something? Has the Mono project actually matured enough to be generally useful?
  • You can create .NET Core apps that run on multiple OSes and CPUs. .NET Core runs on Windows. Ports are in progress for Linux, OS X and FreeBSD, as is integration with the LLVM compiler.


    Then there are interpreters for IoT/FPGA/ARM etc. so there are several platforms. I just thought I'd futureproof my knowledge... ;P
  • And today you need the .NET libraries installed, both for C# and vb.NET. But PC-DMIS needs that (.NET) too, so you don't see the problem...

    And continuing on that track - as C# needs .NET, how can it be useful in any other environment than Windows? Have I missed something? Has the Mono project actually matured enough to be generally useful?


    Microsoft is in the process of open-sourcing .NET, for the sole purpose of making it truly cross platform Slight smile

    https://github.com/Microsoft/dotnet

    http://blogs.msdn.com/b/dotnet/
  • Microsoft is in the process of open-sourcing .NET, for the sole purpose of making it truly cross platform Slight smile

    https://github.com/Microsoft/dotnet

    http://blogs.msdn.com/b/dotnet/


    Cross platform means that your programs can run on any platform unchanged. It doesn't apply to the .NET runtime because this will always be specific to an operating system. The runtime interpreter is what allows your program to work on any supported operating system.

    Microsoft could have released versions of the .NET run time for different operating systems (OS X, GNU/Linux, IOS, ...) but decided to 'open source' it instead. Not sure what this will do. I suspect that most in the free software world are not interested in using .NET anyway due to Microsoft's shifty licenses and probably wouldn't (and likely shouldn't) even look at the source code.

    Also, it is only the core .NET framework. I don't know .NET at all but this sounds like it is bare bones and you wouldn't be able to do much with it anyway. I could be wrong on this point.
  • MS open-sourced .NET Core under the quite permissive MIT license.

    .NET Core will allow open source developers to port a far superior implementation of .NET to other platforms, without fear of future licensing concerns. Mono's .NET implementation for Windows has always been a bit lacking, and they have recently been held hostage for license fees from Xamarin for their proprietary OSX, iOS and Android ports.

    Core isn't a substitute for Microsoft's full .NET runtime, it is the foundation of it. Making Core open source paves the way for an eventual open-sourcing of all of .NET, and ensures its quick adoption by the community. We won't see the full impact of this for some time.
  • Microsoft is in the process of open-sourcing .NET,


    Thanks! This is quite interesting, I had missed it completely.
  • MS open-sourced .NET Core under the quite permissive MIT license.
    ...


    ... and don't forget the promise not to sue for patent infringement:
    https://github.com/dotnet/corefx/blob/master/PATENTS.TXT

    So, it appears that if you write something that uses the MS .NET core as they provided you're safe and cannot be sued. If you modify the code for .NET then maybe your not so safe (you can be sued for whatever patents they have on .NET ?) which brings up the point of why did they even bother to release the source code if they don't want you to change it?

    I don't trust MS at all. I still remember all the antitrust stuff from around 2000 which showed all of their internal tactics for crushing competitors and squeezing the industry. Even though this is ancient history they still do very questionable things (ISO/IEC 29500 ring a bell, maybe Samba/Kerberos?). Why not just release the code with a GPL license and forget about 'promising' not to sue?

    It doesn't affect me since I don't write anything using .NET and likely never will. I know that many in the free software community distrust MS and it would be amazing if they simply decided to 'jump on board' and start writing .NET components without asking questions about what kind of problems they could run into. If the situation is not absolutely crystal clear when dealing with MS then it is assumed to be a problem (a safe assumption usually). Maybe things are different with MS as compared to what they were back in the early days but this is something they have to demonstrate first. A promise not to sue that disappears if you change the code in .NET doesn't sound too different from how they operated in the past.

    I realize this is way off topic. Sorry for hijacking.
  • Hi Cappy,would you pls send me the help file "Windows 7 automation notes"?
    I need some c# demo for developping pcdmis.
    Thank you very much!
    My mail Add:153667861@qq.com