CurrentProject problem

[smig]

I have some problems using CurrentProject

I made an MDE that hold some public functions and is referenced from another db.
Most works well. Only thing causing me problems is the CurrentProject. even if I call it from the refernced MDE it give me the original (The bigger) project.
(The same apply to the Currentdb)

how I can refernce to the MDE itself, and it's objects ?

Thanks,
Tal

 

[MarkK]

Use CodeProject to refer to the project in which code is running, so if you have referenced a library database and code is running in that project use CodeProject. Likewise, the DAO.Database object of the referenced library is CodeDb, not CurrentDb.
Cheers,
Mark

 

[smig]

If I use CurrentDb in the Referenced MDE will it read tables from the container app ?

 

[MarkK]

If you have two databases and A references B, then CurrentDb--and CurrentProject--always refer to A. CodeDb and CodeProject, however, always depend on the context and always refer to the project/database in which they occur. So if you wanted to expose a custom object from your library database B that used tables in that file, you'd need to use CodeDb. If you used CurrentDb in B you'd refer to the database in file A.
Cheers,
Mark

 

[smig]

Thank you for the help

 

[smig]

If I put this function in the refernced file (File B) will it know where the frm came from ?
MyFunction(frm As Form)

 

[Galaxiom]

I think you might be looking for the Run Method.

 

[MarkK]

Does it matter where the frm came from? If so, I don't recommend putting it in a library database. The advantage of setting a reference to a file, either a database or an object model like DAO, is that the referenced file provides a generic or abstract functionality AND portability.
So if you have a series of functions you find you reuse a lot, or you've developed an easy-to-invoke selection interface, or wizards for common tasks, or toolbars, then put those in a library file, and design your library so it doesn't care where it gets requests from. Design it so it works with any frm, and if it doesn't, maybe it belongs in the production database (File A) that uses the library.
See what I mean? Did I understand your question?
Cheers,

 

[smig]

Thanks,

@Galaxiom - The run method gave me little help here, but thatnks. It might be usefull at other times

@lagbolt - you did understand my question, and this is exactly what I'm doing.
I'm developing an application that will be splited into several ones (all share the same data).
All will share several functions, and several forms, which I want to put in a single MDE that all will reference.
Some of these shared forms (Like a ZoomBox one) read data from the cntainer app form, and this is why I need to know if using the code I asked about will work.

I did test the thing and it seems to know where the form come from, so it won't care if it's from file A or file B

 

[vbaInet]

In my opinion library functions shouldn't be referencing form objects or it's associated controls. You can pass the value of a control to it but not the reference to the control and they should simply return a value, not set the value of a control.

I think this is somewhat related to lagbolt's point.

 

[smig]

some of the library functions I use are for setting automation function for objects. this is why they must know the form and controls to set the function for.
It seems to work nicely.

Having these functions in one library will mak my life easier at later time when I need to update.

 

[vbaInet]

some of the library functions I use are for setting automation function for objects. this is why they must know the form and controls to set the function for.

This is my point. If you can pass the reference to the control, you can get the value from the function and pass it to the control outside the function.

E.g (aircode):

Database A calls lib db Database B:
B.SomeFunction(Me.ControlName)


Sub SomeFunction(ctl As Control)
    ctl.Value = Some operation
End Sub

If you can do the above, why don't you do:

Database A calls lib db Database B:
Me.ControlName = B.SomeFunction(Me.ControlName.Value)


Function SomeFunction(strValue As Variant) As String
    SomeFunction = Some operation
End Sub

So instead of passing references back and forth, you are simply passing and returning values.

 

[smig]

I totaly agree with you about this.

But what I do is a different thing:

sub Form_Load()
 
Call MyLib.SetLoad(me)
 
End sub
 
' --- These go into library
Public sub SetLoad(frm as form)
dim ctrl as Control
....
 
for each ctrl
....
  .OnMouseClick = "=OnMouseClickFunction()
....
next
 
.....
End Sub
 
 
Public Function OnMouseClickFunction()
.....
End Function

I guess you get my point.
This is why I need the form and it's controls.

 

[MarkK]

Another tidbit you might like, is you can define classes in your library and use those classes in your production database. To do so...
1) Create a class in the library database and make sure that module is current in the IDE
2) Open the Properties window and note that the class has a single property called Instancing. Set this to '2 - Public Not Creatable'
3) And to return an instance of that class to consumers, in a standard module expose a public function that returns a new instance, so something like...

Public Function GetNewClass As clsMyNewClass
  set GetNewClass = new clsMyNewClass
End Function

4) So now, if a FileA references a library FileB, FileA can use the class defined in the library like this...

private sub test180674
  dim tmp as FileB.clsMyNewClass
  set tmp = FileB.GetNewClass
[COLOR="Green"]  'tmp now contains a new and strongly typed instance of a class defined in the library[/COLOR]
end sub

5) Cheers, (for vbaInet)

 

[smig]

Thank you lagbolt but I still try to learn the proper use of classes.
I do have some classes in my projects I took from other places, but I still don't fully understand the idea of it, so I doubt I can write my oun

 

[Galaxiom]

I do have some classes in my projects I took from other places, but I still don't fully understand the idea of it, so I doubt I can write my oun

Classes are really worth learning.

Chip Pearson's introduction to classes is very good. It covers all the most important features.

 

[vbaInet]

5) Cheers, (for vbaInet)

I'm still trying to implement this step. I'm stuck. Help!

I guess I'll just stick to the whiskey then.... cheers!

 

[smig]

I'm still trying to implement this step. I'm stuck. Help!

I guess I'll just stick to the whiskey then.... cheers!

Drink one for me too

 

[vbaInet]

Drink one for me too

Trying to get me drunk!!!