samuel-t

Thanks/Tack. /Samuel

Just dropped by to say hello. Added some responses to some VB6 related questions. Read some. Enjoyed myself. But it's way past midnight in Stockholm, Sweden right now, so good night t'y'all. /Samuel

Keep them private in the module, but make the sub 1.) not a sub but a function, and 2.) public. Like this: Option Explicit Private Const SW_SHOWNORM = 1 Private Const SW_SHOWMIN = 2 Private Const SW_SHOWMAX = 3 Private Declare Function ShellExecute Lib "shell32.dll" _ Alias "ShellExecuteA" (ByVal hWnd As Long, _ ByVal lpOperation As String, ByVal lpFile As String, _ ByVal lpParameters As String, _ ByVal lpDirectory As String, _ ByVal nShowCmd As Long) As Long Public Function OpenThisFile(ByVal WhichFilePath As String) As Long OpenThisFile = ShellExecute(0, "Open", WhichFilePath, 0, 0, SW_SHOWNORM) End Sub And call it from every place that you want to call it from, such as your Command Button, like this: Private Sub cmdOpen_examplehtml_Click() Dim r as Long r = OpenThisFile("c:\some\file\somewhere.txt") If r <> 0 Then MsgBox "Failed to open file." End If End Sub Oh, and NO NO NO -- it doesn't help anything in any way if you put your application in the same directory as the VB6 runtimes. It has nothing to do with that at all. Either the VB6 runtimes are available somewhere on the system where your application gets installed (and it is quite likely that they are) and then your application can run on that system, or they aren't available, in which case your application can't run on the system. You should, however, never (well, if you distribute on CD, sure, but not if you distribute over the web) include the VB6 runtimes in an installation file, but let the people who download your application know that if they don't have the VB6 runtimes installed (tell them how to check for it -- such things are always appreciated and provide them with a link fr download. /Samuel

Check out http://vbAccelerator.com/ -- he's got some great examples of how to do it. He also got lots and lots of great code, controls and snippets all over the place. Highly recommended for anyone coding in VB5, VB6 or VB.Net /Samuel

The trick (as I know it in VB6) is to begin the whole project with the creation of a dll that will be the host for your plugin stub -- which is a cls file, let's call this one "wtStub" -- and perhaps some generic string/form/number manipulation classes. Call the project something like "cjWinTwekStuff". Add some properties &/ methods... Option Explicit Public Property Get StubName() As String ' End Property Public Function Add(ByVal PropKey As String, ByVal PropVal As String) As Long ' End Function Public Sub Process() ' End Sub Public Property Result() As String ' End Property Compile this into a dll, and, hey; remember to set it's compatibility to "Project" or you'll end up in DLL Hell when you come to the conclusion that you want to add something to your dll and recompile it and nothing matches... Start a new ActiveX DLL project. Open the cls file. Type the following... Option Explicit Implements cjWinTwekStuff.wtStub If you know look under the object drop down list box in the coding window, you'll notice the object "wtStub" there. Click it, and in the other drop down box, you'll find all the available properties and methods of "wtStub". NOTE: You can't, which you can when it comes to instances of regular controls, skip any property/method. You must implement them. But implementing them is as easy as clicking the name in the drop down menu and adding a ' instead of any code, like this: Public Property Get wtStub_StubName() As String ' End Property But on most occasions however you propably would like to do something inside the plugin so... Option Explicit Implements cjWinTwekStuff.wtStub Dim PropKeysVals As Collection Private Sub Class_Initialize() Set PropKeysVals = New Collection End Sub Private Sub Class_Terminate() Set PropKeysVals = Nothing End Sub Public Property Get wtStub_StubName() As String StubName = "Win Tweak Do Something" End Property Public Sub wtStub_Add(ByVal PropKey As String, ByVal PropVal As String) PropKeysVals.Add PropVal, PropKey End Sub Public Sub wtStub_Process() 'Do something. I don't know what. If you want to you can open a window here (only vbModal I'm afraid, but still) or something... End Sub Public Property wtStub_Result() As String 'Return the result of what you did in Process. End Property Compile this into a dll. Call the class say "DoSomething" and the dll "wtPlgDoSomething". Once again, remember the "Project" compatibility. Anyho. Start a new EXE project. Double-click the form and in the top of the form enter... Private pPlugins() As cjWinTweakStuff.wtStub ... And in the Form_Load event type this... Private Sub Form_Load() Redim pPlugins(1) Set pPlugins(0) = CreateObject("wtPlgDoSomething.DoSomething") 'Redim Preserve and add more plugins. End Sub Ok. So here's the catch (there's just got to be one): Look at the name of your plugin. Look again. How does your application even know that there are plugins available when they have to be named things like "wtPlgDoSomething.DoSomething"? The quick answer is: It doesn't. So you have to find a way of letting your application know that there are plugins. The strategy I use in one of my creations (which is on, I don't know, a delta stage when it comes to the GUI, and a beta on the rest, maybe) is to let my application scan a directory for files with a certain extension and then take the rest of the filename and try to call CreateObject on that part (in your case, maybe the extension could be something like ".wtplg", which would name your file "wtPlgDoSomething.DoSomething.wtplg"). On failure I log a message, and on success I read the properties of the plugin and store them in an internal plugin handler class in as a Type in an array of Types of my own, matching design and then I set the newly created object to nothing and proceed to the next. Why do I do this? Because of Error 47. "Too many DLL application clients". The VB Runtime can only handle 50 simultanious instances of applications &/ dll's and ocx's, therefore "you must not waste resources or you'll be wasted by thy neighbour". Or at least disliked. To continue to the next problem: How does your plugins know where to install their wtplg files &/ themselves? The way I see it is that I avoid the registry as much as possible, because it is downright clumsy if you, as an end user, want to move an application from one place to another (for backup purposes for instance), and I want to make the use of applications that I write as slim and intuitive as possible where possible. Still it is absolutely great when it comes to letting two applications know the whereabouts of each other. So add your application to the registry and let the plugin installation program look for that particular key in the registry and then install to the correct subdirectory. If you let your application do this on startup, and correct the path if it is wrong, you'll always (well, not really, but see bellow for that) be able to distribute plugins that install to the correct location. And that's nice. Welcome to the "always (well, not really" part. I can think of one occasion where it fails and that is if someone move you application from one directory to another and doesn't start it, but immediately start to install plugins. Then the registry entry will point to the old directory. That is solvable too, for instance by letting your plugin installation program detect that a certain directory is empty or doesn't exist and then let the user select the directory where your application actually resides. Maybe that will get you started in the right direction...? Best wishes /Samuel