Might need to see more code, it doesn't sound like the function is being exported. Is the function in the @EXPORT or @EXPORT_OK list in the module? Is Exporter used in the module? Do you say 'use Module qw(function);' in the script if its in EXPORT_OK, or just 'use Module;' if its in @EXPORT? Is Exporter in the @ISA list in the module?

Update: The 'undeclared' error I was talking about is about when you said "I tried removing the my $opendir", and you said that you get an error about it being used later...

Anyway, as others have said, did you forget the package declaration in the module ('package NotesOLE;' if that's the name of the module, and the filename is 'NotesOLE.pm')? Is the module 'NotesOLE'? If not, you need to use it in the main script.

I use strict and warnings on both, is there a problem with that? I am not sure what undeclared variable you are talking about? $var1 and $var2 are declared earlier in the script and $openreturn is declared inline.

------------------------------

Module NOTES

use strict;

use warnings;

use Win32::OLE;

use Win32::OLE::Variant;

use Date::Manip;

use base 'Exporter';

use vars qw($VERSION @EXPORT @EXPORT_OK);

($VERSION) = ' $Revision: 0.1 $ ' =~ /\$Revision:\s+(^\s+)/;

@EXPORT = qw( OpenNotes CloseNotes FetchNotesDoc Search FTSearch ); # Exported by Default

@EXPORT_OK = qw(); # Exported if Reference

rest of code

-----------------------------

Test Script test.pl

use strict;

use warnings;

use Win32::OLE;

use Win32::OLE::Variant;

use NotesOLE;

Bunch of variable stuff

my $openreturn = OpenNotes($dbname,$server);

Rest of code.

---------------------------

It is my understanding that if you use base 'Exporter'; you don't have to declare @ISA in vars, I tried both and had no success!

Tried Export(..) with use Module and Export_ok(…) with use Module qw(sub);

Thanks for the response.

</BODY> </HTML>

From the code you posted, it looks like you may have forgotten the package declaration in your module. You should add a package NotesOLE; at the top of your module.

Curiously, although the missing package declaration would prevent perl from calling the module's import method, it should also cause all of the module's methods to be declared in package main in the first place. So, there may be something else going on to cause the Undefined subroutine &main::OpenNotes called ... error. Do you have another module which loads NotesOLE before test.pl does?

Anyway, put in the package declaration and see what happens.

Hmm. Maybe just a copy-and-paste thing, but in the first part you say your module is named "Notes", but in the sample of test.pl it says "use NotesOLE". Check for typos in the package and file names (although strict should have caught things like that). Otherwise I don't see anything obviously wrong with your code.

HTH

May be it is out of the thread but I must say a word.

Be carefull with base pragma, it will only require your base modules, not use them! So import subroutines of the base modules will be ignored.

A spot from documentation:

-----------
    package Baz;
    use base qw(Foo Bar);
[download]

Roughly similar in effect to
    BEGIN {
    require Foo;
    require Bar;
    push @ISA, qw(Foo Bar);
    }
----------
[download]

An example:

----------
### File A.pm
package A;
sub import { warn "A imported"; }
----------
### File X.pm
package X;
use base qw(A);
sub import { warn "X imported"; }
----------
### File Y.pm
package Y;
use A;
use base qw(A);
sub import { warn "Y imported"; }
-----------
### File Z.pm
package Z;
use A;
@ISA = qw(A);
sub import { warn "Z imported"; }
----------
[download]

And now:

bash$ perl -e 'use X'
import X at X.pm line 7.

bash$ perl -e 'use Y'
import A at A.pm line 5.
import Y at Y.pm line 8.

bash$ perl -e 'use Z'
import A at A.pm line 5.
import Z at Z.pm line 9.
[download]

You can see base module A is not imported in the first case.

-- brother ab

my $notesreturn = &ModuleName::OpenNotes($var1, $var2);"
[download]

... where "ModuleName" is the name of the module that you've created. Also, make sure that your module is loaded up correctly in @INC.

Tried this and it didn't help. The test script is in the same directory as the module and it caught some errors in the module when it first loaded. So I think that the module is loading fine.