jwcolby
jwcolby at colbyconsulting.com
Wed Dec 12 07:56:14 CST 2007
Andy, >1. In your example you gave a set of lines and their replacements. Do the lines BEGIN MultiUse = -1 'True END remain? Nope, remove those lines. It turns out that Access "recreates" all that stuff behinds the scene when it creates a class, and it is all invisible to us from inside of the class when working in the editor in VBA. You can leave it in, or take it out, it makes no difference. I just take it out because it "simplifies" what I am looking at when viewing the class out in the text editor. >2.If I modify the class and save it will the changed attributes persist, or will I have to go through this malarkey again? What happens is that these properties are "set" inside of the class as you import them from the text file. If you were to export the class again you would see that they are still set to the values you set them to the first time. >ROTFL. I like your style JC. Tell me to do something that Shamil says not to, then say to blame Shamil if it goes pear-shaped. Harsh. Not only that but I used Shamil's own "don't do that" email to tell you to do it. <HUGE grin> We live in strange times. Shamil lives half way around the world from me and yet I consider him a good friend, as I do many other people on this list that I have never met. And of course, since much of what I learned in this area came directly from Shamil, if anything goes wrong, IT IS SHAMIL'S FAULT. ;-) Shamil's cExposer performs all these steps for you from a point and click environment. I have never used cExposer myself, though I might. I have only ever exposed normal class modules, never modules behind forms or reports. Understanding how to do the process manually is important I think, and allows me to "just do it" whenever I need to. It really is easy enough to do. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Andy Lacey Sent: Wednesday, December 12, 2007 7:31 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Classes In Referenced MDE ROTFL. I like your style JC. Tell me to do something that Shamil says not to, then say to blame Shamil if it goes pear-shaped. Harsh. Anyway I'm going to try this. Sounds a breeze. A couple of questions though: 1. In your example you gave a set of lines and their replacements. Do the lines BEGIN MultiUse = -1 'True END remain? 2.If I modify the class and save it will the changed attributes persist, or will I have to go through this malarkey again? Thanks for your help. -- Andy Lacey http://www.minstersystems.co.uk --------- Original Message -------- From: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> To: "'Access Developers discussion and problem solving'" <accessd at databaseadvisors.com> Subject: Re: [AccessD] Classes In Referenced MDE Date: 12/12/07 13:17 Andy, >There are also "dirty" tricks to make custom classes in MDB/MDE >creatable using New keyword in FE but I'd not recommend using them And I do recommend using them, having used them myself for years (since I learned of Classes from my mentor Shamil). The method involves exporting the classes to a text file. 1) Click on a module from the database window: 2) Click File / Export (from the menu) 3) A file find dialog will open. I usually make a CLASS directory inside of my project directory. Move to that directory. 4) type in the name of the file to save it as. Make the file name the same as the class name that you are exporting. 5) Open the text file with an editor. Inside you will see the following at the top of the module: VERSION 1.0 CLASS BEGIN MultiUse = -1 'True END Attribute VB_Name = "dclsMail" Attribute VB_GlobalNameSpace = False Attribute VB_Creatable = False Attribute VB_PredeclaredId = False Attribute VB_Exposed = False Option Compare Database Option Explicit 6) Replace all of that with the following: Attribute VB_Name = "dclsMail" Attribute VB_GlobalNameSpace = False Attribute VB_Creatable = True Attribute VB_PredeclaredId = False Attribute VB_Exposed = True Notice that I replaced VB_Creatable with a True value and VB_Exposed with a true value. 7) Leave the rest of the file untouched, modifying only the lines as shown above. Save the text file. 8) Back in the database delete the class you just exported. 9) From the database window click Insert / Class module (from the menu) 10) The VBE will open in a new class. In the text editor click Insert / File (from the menu) 11) A file find dialog will open. Navigate to and select the file you just modified out in the disk. It will import the class back in to the database container (library). The text file will load into the class module. NOTICE that the properties that you modified out in the database window are not visible. If you could see or manipulate those properties from inside of the editor this whole export / modify / import rigmarole would not be required. IIRC you CAN do that in VB6 (though I am not a VB6 guru). 11) It will ask if you want to save, say yes. That class will now be referencable and creatable from outside of the library. That is it, you are done. You are now a member of the ELITE programmers able and willing to use undocumented tricks to do things others only dream of. 8~0 IIRC you also have to do this if you intend to RETURN a class from a function, IOW you can't create a function function CreateMyClass() AS clsMyClass end function then you must go through this process for clsMyClass even if you never intend it to be seen outside of the library. I use this process myself (I am "Mr. Framework" after all), but ONLY for classes that need to be exposed to the outside world, simply because not performing this process makes a class private to the library, i.e. only referencable from inside of the lib. You should never expose things that you do not want anyone seeing outside of the intended scope. Shamil does not recommend this method because these properties (and they are properties of the class) are undocumented IN VBA by MS and thus "subject to change". However they are also used in VB6 (where they are directly exposed IIRC) and so the chance of this process being prevented in the future is vanishingly small. It has been usable since A97, well over 15 years, and is still usable in A2007. My framework wouldn't function if I did not use this trick. Use it without fear. HOWEVER... if the process ever does fail (and it hasn't in all the time I have used it) simply say: IT'S ALL SHAMIL'S FAULT! ;-) John W. Colby Colby Consulting www.ColbyConsulting.com