I can suss it all just fine, and it sounds like your only fault is that you're just beginning to learn about programming in Access with VBA. And that isn't a fault. That's just "starting out". Read this, and you'll be much more fine; hopefully then, Access will look less like the anti-Christ and more like, ummm, an interesting maze that you're beginning to map?
Sorry, I can't help but chuckle (at our simple humanity)
. One of us did miss something obvious, and without going back to check, I actually don't know which of us (heh) . A third of that code goes into the module of a *form*! (All the code that includes the keyword 'Me'.) I haven't gone back to review my other post, so I don't know if it mentioned a form, or if that was part of the context in the thread, but whatever
. The other two thirds go into separate modules. These were the key facts you missed. More follows a little further down.
The Me keyword is reserved exclusively for use within Forms and Reports, and is a way to refer specifically to "the particular instance of the form/report running the code containing this Me". So if you have multiple instances of a "Display Book Summary" form running at the same time, if the user clicks a button on one of the instances of the form, a 'Me' in the code of that button would refer to the form instance on which the button was pressed, not any of the other instances. And if they clicked the "same" button on a different instance of the form, the 'Me' in that button's code would refer to *that* instance of the form. And so on. Does my explanation make sense? If so, then you now know something more about form/report programming.
Those procedures that begin with "cmd" and end in "_Click()" are the Click event handlers for a CommandButton. (Thus, "cmd" as the prefix; this is part of a standard nomenclature for naming VB/VBA controls/objects/variables/things. Look around for information about the "Reddick naming convention". This convention helps to make code self-documenting, if it is followed consistently, and if the reader knows the convention, of course.)
So "cmdGetFileForOLEobject_Click()" is the event procedure (yes, a sub) for a CommandButton called "cmdGetFileForOLEobject". (If I just type "button" at some point further along in this post, I probably do mean "CommandButton" rather than "ToggleButton" or some other kind.) "Event handler/procedure" means "the code that runs when the event in question is triggered". In *this* case, the code that runs when the button is clicked.
Nothing I've posted has anything to do with, or any need for, macros. And in fact, I don't use macros, because VBA is much more powerful and flexible, since I know how to use it well. (No condescension, just information.)
cmdGetFileForOLEobject_Click calls the ShowOpenFileDialog function to display the Open dialog (the Common Dialog control, in 'Open' view). So the user clicks the button, gets a dialog in which they can browse to a file -- you will want to change the default starting directory and the list of filters the dialog uses, for your project -- and the program loads the chosen file into the OLE field.
The 'Edit' button, whatever I called it, works in conjunction with the 'In Place/Outside Access' toggle button immediately next to it. The 'Edit' button opens the file/object contained in the OLE field for editing, or activates it. When it goes to do so, its code checks the state/value of the ToggleButton and uses that to decide whether to do the editing in place, inside Access' window and my form, or outside Access, in a stand-alone instance of the editing application.
So you need a form, and two separate modules. My code has comments in blocks made of equal signs, telling you how to divide up the code, which sections of code go into which modules.
0) First note that
Code:
Option Compare Database
Option Explicit
really belongs at the start of each of the modules (including the form module). It shows up in my copy of the mdlOpenFileDialog code because I copied that entire module; it doesn't show up in the others, because I only included the necessary relevant portions of those modules instead of a Select All and Copy & Paste. (The other modules also included code that had nothing to do with the OLE field.)
1) The form has to have a bound OLE control, two CommandButtons, and a ToggleButton, for my code to work. Also, the control names in the code and on the form have to match, of course. (If I just missed mentioning a control or something, it will come up unrecognised when you compile, and you should be able to recognise the control name after reading about syntax and exclamation points further down; and I'm happy to answer regarding them, too.)
2) The ShowOpenFileDialog() function and attendant code belongs in its own module, mdlOpenFileDialog.
3) The name of the second module is mdlUtilities, and it contains -- you guessed it -- some code of general utility, my Replace() function.
I *think* I specified these things in the post containing the code, but I'll go back to check. ... Yeah, here's a relevant portion of the post, right near the top: "Here's a bunch of code, separate subs and functions, from a form I built. I also included the code from outside the form module, which is invoked by the form code." Don't worry too much about missing it. We all get in a hurry and skim or miss stuff from time to time.
Yeah ... read all the intro paragraphs; they explain what the code is doing and how. The code alone isn't quite enough, especially if you take it to be a single piece. But do keep writing back if you have other questions!
![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")
As for the Me![object name] syntax:
You typed "Me.[oleObj]", but I used "Me![oleObj]". This is an *important* difference when reading the code. The exclamation point is better documentation *and* better code. (You *can* use a dot instead of an exclamation point, but it isn't good. Using the dot while typing the code in the VBA editor gets Access to list all of the properties, methods, and controls of the form for you so that you don't have to type or recall the whole name of whatever you whichever one you want to reference. But the exclamation point specifically references the default collection, instead of adding a level -- referencing the default property, which returns what-happens-to-be-the-default-collection. Clear as mud? Read it again after reading the next two paragraphs, which explain more.)
Okay, so … You now know that Me refers to a specific form (the one running the code containing the Me). The brackets are *required* if the field/control name inside them contains a space or a pound-sign, but I always try to use them whether required or not, for consistency's sake, and as a visual documentation. They are used for control/field names, but not for anything else like property or method names. In this way, the brackets provide good visual documentation; what they enclose is a field or control name.
Detail about the exclamation point:
(Actually, *after* typing what follows, I found a succinct description in the help, looking in the index under "! (operator)" then choosing "Use the ! and . (dot) operators in expressions". Read that. But after already having typed what follows, I'm leaving it as a supplement to the help.)
What the exclamation point actually signifies is that what precedes it is a collection and that what follows it is a member of the collection named before the exclamation point (i.e. [Collection Name]![Member Name] shows that the thing named Member Name is a member of the collection named Collection Name). In Access, this syntax applies to all collections and their members. Since Access allows default properties/collections, sometimes you see something named before an exclamation point that isn't a collection -- but in these cases, it is implicitly assumed that the default collection is being used, preceding the exclamation point -- in effect, the collection reference is there, even though you can't see it. In the case of Forms, I quote the help for the Form object:
----
Each Form object has a Controls collection, which contains all controls on the form. You can refer to a control on a form either by implicitly or explicitly referring to the Controls collection. Your code will be faster if you refer to the Controls collection implicitly. The following examples show two of the ways you might refer to a control named NewData on the form called OrderForm [Note that the Forms collection is a collection, too, and so also uses the exclamation point. -- CVigil]:
' Implicit reference.
Forms!OrderForm!NewData
' Explicit reference.
Forms!OrderForm.Controls!NewData
----
The default property of a form is the .Controls property, which returns the Controls collection, as I mentioned earlier. So Me.[controlname] works, as it implies the .Controls property which returns the Controls collection of which controlname is a member -- but Me![controlname] is actually preferable, and better. And when you see the brackets, you can be sure that what's inside is not a property or method name, but a member of a collection; in the context of the form reference (Me), it's a field/control name. So you see, even if the brackets aren't necessary (I avoid spaces and pound signs in names at all cost), they are useful and brief visual documentation.
That's all I can think of for now...
I think I've provided what you need to try again and move forward. And don't worry; from my side, it's clear you'll get there.
-- C Vigil =)
(Before becoming a member, I also signed on several posts as
"JustPassingThru" and "QuickieBoy" -- as in "Giving Quick Answers"
![[pipe]](/data/assets/smilies/pipe.gif "[pipe] [pipe]")
.![[tongue]](/data/assets/smilies/tongue.gif "[tongue] [tongue]")
. You don't have to use it anywhere else.) And it stays around for the entire time the database is used.