Test for existence of procedure

[Glasgow]

Is there a way to test if a procedure exists in a form before trying to call that procedure and without using an error trap?

Something along the lines:

If ProcedureExists(OtherForm.SpecialProcessing) then Call OtherForm.SpecialProcessing

 

[MakeItSo]

Errr - by opening in design mode?
OK, let's be serious...

With some adaptation, this might help:

Function ProcExists(FormName as String, ProcName as String) as Boolean
Dim Cod as string
Cod=vbe.VBProjects(1).VBComponents(FormName) _
.CodeModule.Lines(1, .CodeModule.CountOfLines)
If instr(1,cod,"Sub " & ProcName)<>0 then 
  ProcExists=True
Else
  ProcExists=False
Endif

This has been "adapted" from some totally different code, so it's untested, but might give you an idea.

Cheers,
MakeItSo


[blue]The last voice we will hear before the world explodes will be that of an expert saying:
"This is technically impossible!" - Sir Peter Ustinov[/blue]
andreas.galambos@bowneglobal.de
HP:

http://andygalambos.de

 

[sciophyte]

just to get an idea of what you want to be able to do that for...why would the procedure not exist if you wrote and compiled the program...what is the check for?

 

[MakeItSo]

Oh damnit! Wrong forum.
This is VB 5.... forget my post...

 

[Glasgow]

MakeItSo - I see where you are coming from but presumably this will only work if you are running on the development machine where the source code resides. I am afraid that this has to work on customer machines where they only have the EXE.

For the moment I'm using an error trap (though I hate them) as follows:

  Dim ErNo As Long
  On Error Resume Next
  Fm.Frm.LfnCallBack (PassTxt)
  ErNo = Err.Number
  If ErNo <> 438 Then Err.Raise ErNo ' ErNo 438 non
-fatal - procedure does not exist
  On Error GoTo 0

sciophyte - it's a rather long story but many of my forms and modules call library routines to do standard jobs (e.g. handle processing revolving around click of an Add button). I want the library to be able to do a callback to the originating form/module if it needs to do any additional 'non-standard' processing of its own. However, I don't want to include an empty procedure in forms that don't need the procedure at all. Hope that makes some sense!

 

[strongm]

>Hope that makes some sense!

Not entirely. At least, not to me...

 

[Glasgow]

Now I didn't say complete sense, did I? So 'not entirely' suggests some sense perhaps?

How about "it's a bodge" then? Not completely true but saves me trying to justify my actions further.

 

[MakeItSo]

How about transferring on e omre parameter - the originating form - to the respective module. You don't need the feature for all modules, I guess.

Would that be an option?

Andy

 

[Glasgow]

>on e omre parameter

not sure what you mean by this?

 

[johnwm]

? one more ?

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'If we're supposed to work in Hex, why have we only got A fingers?'

 

[MakeItSo]

My fingers haven't typed what I wanted them to.....
This should read one more parameter

...on e omre... sounds italian....

 

[Glasgow]

Sorry - too early in the morning for me to suss. I thought I was about to be enlightened on another acronym (ADO, DAO, OLE, ODBC & ..... OMRE).

Yes parameter was an option and, if I'd made it optional, I need only have changed offending module but I quite like the idea of keeping logic that is specific to the module within the body of its own code.

To be honest, the whole rationale behind the coding of these forms, modules and libraries was based on my early exposure to VB - I would probably do it all quite differently if I had to start again but I don't have that luxury.

Thanks for your help.