juo has asked for the wisdom of the Perl Monks concerning the following question:

I have been trying to re-write some VB OLE code into Perl but have some problems with function calls that use anobject variable. That variable will be set by the FindPart method in my example. I don't know how to create the "out" variables in Perl. Particular the line : if $Library->FindPart($placement->PlacementPart->Part->Name, $Part) is causing problems. Any ideas ?

VB CODE 

Dim Part, FeederType
If Library.FindPart (Recipe.Placements(0).PlacementPart.Part.Name, Par
+t) Then
   FeederType = Part.Value ("FEEDERWIDTH", "Default value goes here")
   MsgBox "Feeder type: " & FeederType
End If

[download]

Perl CODE 

my ($Part, $FeederType);
for my $placement (in $Recipe->Placements)
{
    if $Library->FindPart($placement->PlacementPart->Part->Name, $Part
+)
    {
         $FeederType = $Part->Value("FEEDERWIDTH", ""); 
    }
}

[download]

Replies are listed 'Best First'.
Re: Trying to re-write some VB-OLE into PERL-OLE
by Courage (Parson) on Sep 23, 2004 at 17:30 UTC
[reply]

      courage, you made my day today, it is indeed the usage of Variants that was required in this case, still a little bit difficult for me to understand but at least I can make it work and move on now. Thanks a lot and thanks to jdporter for having faith in me, he gave me the courage to keep looking, and it did not take six months. :-). Just for the record the piece of code. 

      for my $placement ( in $Recipe->Placements)
{
            my $PartNum = Variant(VT_VARIANT|VT_BYREF, ""); 
            $Library->FindPart($placement->PlacementPart->Part->Name, 
+$PartNum);
            my $FeederType = Value{$PartNum}->MachineValue("FEEDERWIDT
+H") ;
}

      [download]
[reply]
[d/l]
Re: Trying to re-write some VB-OLE into PERL-OLE
by dragonchild (Archbishop) on Sep 23, 2004 at 13:41 UTC
    Uhh ... a few questions:
    • Why are you rewriting what is presumably a perfectly good VB app? If it ain't broke, don't fix it.
    • Have you actually learned Perl? Perl isn't VB rewritten as if cartoon characters were swearing. Perl's ancestry is actually very different from VB's ancestry, going back several language generations.
    • Do you have a design document for this application? When I have rewritten apps from one language to another, especially from XYZ to Perl, I have found it simpler to start over rather than to "translate". Plus, you get better Perl code.

    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";
}

    [download]

    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

[reply]
[d/l]
      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.
[reply]
[d/l]
        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

[reply]

      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.

[reply]
        *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

[reply]

Back to Seekers of Perl Wisdom