in reply to Trying to re-write some VB-OLE into PERL-OLE

Uhh ... a few questions:

Your question is demonstrating a very keen misunderstanding of Perl. If I correctly understand what you're trying to do, you actually want the following Perl code:

if (my $part = Library::FindPart( $Recipe->{Placements}[0]{PlacementPa +rt}{Part}{Name} ) ) { my $feedertype = $part->Value( "FEEDERWIDTH", 'Default value goes +here' ); print "Feeder type: $feedertype\n"; }

Now, that code assumes you know a WHOLE bunchload of Perl idioms, data structures, object-oriented code, etc. Unless you really want to spend at least 3-6 months immersed deeply in Perl, I would strongly suggest you fix the bugs in your VB app and not use Perl.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re^2: Trying to re-write some VB-OLE into PERL-OLE
by jdporter (Paladin) on Sep 24, 2004 at 00:18 UTC
    Do you do any Perl OLE programming yourself, DragonChild? I do... and while I don't know anything about this "Library" component's object model, what juo wrote looks like perfectly fine Perl code, except for the missing parentheses around the condition of the if statement.
      I have tried to get into OLE, but the documentation from the Perl side is poor and I don't like reading Microsoft's docs. They assume too much about what you're trying to do. *shrugs*

      I still maintain that if the VB code works, it should remain in VB, but that's just my opinion.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

        You have a valid point; I can't count the hours I've wasted rewriting stuff just for the heck'a. But OTOH, translating code from a language you know into a language you don't is one of the ways you can gain some familiarity with it. (Of course, it should be only a small part of this nutritious breakfast... ;-)
Re^2: Trying to re-write some VB-OLE into PERL-OLE
by juo (Curate) on Sep 23, 2004 at 14:10 UTC

    Well it is not from a VB script it is a sample I have received from the writers of the application and they have no design code of the application so I have been doing trial and error. The reason why I don't use VB is because I am not so familiar with VB and because I swear by the HASH tables of Perl and the easy to read language (sometimes :-)). If I ran your sample however I will get an error, not an ARRAY reference and if I try to modify it to contain the Perl Object links it will say undefined subroutine &Library::FindPart called. Well my Perl is that from a non-professional but however so far I have been able to do everything I want in Perl, besides from those crazy OLE objects which give me headachs.

      *sigh* That's my point. Those "crazy OLE objects", as you call them, are actually an extremely sophisticated framework within which to write applications. Replicating them in Perl is actually quite difficult and extremely time-consuming. And, it sounds like you want them replicated.

      You're not going to want to hear this, but if you are bound and determined to pursue this, you are going to spend a lot of time doing one of the following items:

      • Learning the ins and outs of Perl to a professional level.
      • Reverse-engineering a design document from the existing code, then writing a Perl application from scratch.
      • Learning the ins and outs of VB to a sufficient level.
      • Finding the necessary funds to pay a Perl and/or VB developer to do it for you.
      Those are your only sane options. Period.

      The first three options are going to take you at least 3 months each, and possibly longer. Frankly, I strongly suggest you take the time to learn VB. I mean it. It will be easier to do and stand you in better stead. Plus, VB does have hashes - you just have to know how to do them.

      The fourth option is completely dependent on your budget. There are plenty of developers who would be delighted to take on this kind of project, myself included. You are going to pay at least US$50/hr for this person, if not close to twice that. But, it will be done in less than a month.

      *shrugs* It's up to you, but it doesn't sound as if your current skills are up to the task you have set for yourself. I'm really sorry to be the one to tell you that, but I'm just being honest.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested