Overflow Error with GetModuleFileName() on Windows Vista
in [Visual Basic]
|
Prev: VB6: Overflow Error with GetModuleFileName() on Windows Vista
Next: my VB6 app does not work in a foreign country
From: Ulrich Korndoerfer on 28 Jan 2010 21:46 Hi Karl, Karl E. Peterson schrieb: > on 1/27/2010, Ulrich Korndoerfer supposed : >>>> Private Function IsInIDE() As Boolean >>> >>> Why don't you use this non-API version instead? >>> >>> http://vbnet.mvps.org/code/core/isinide.htm >> >> Because they differ in their result. >> >> Eg if you have a compiled dll with the IsInIDE test and use that dll >> in an application, if the application is run in the IDE the latter >> will deliver False, the other True. > > That'd be pretty dumb, to ask a compiled component whether it's running > in the IDE, wouldn't it? Maybe I don't understand the objection. I can think of several purposes: - a tools dll that is used by your applications and contains for your convenience as one of the tools the IsInIDE function. Here the tools dll (which is supposed to be used compiled also during application development) should report True, when the *application* that uses it is running in the IDE. Using the Debug.Assert trick then is not the way to go. - the dll on its own needs to differentiate wether it is running compiled or not (typically when the dll uses subclassing). Here the dll uses its IsInIDE function itself and so the function then should report True when the dll itself is running uncompiled in the IDE (because it is in a project group with the application that uses it). Btw it is easier to simply check the return value of GetModuleHandle("VBA6.dll"). This dll is loaded in the process space (at least if not the user's code loaded it) only when the app is running in the IDE. So it depends on the use case wether for IsInIDE functionality the Debug.Assert way or the Api way is used. Or did now I misunderstand you? -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
From: Karl E. Peterson on 28 Jan 2010 22:17 Ulrich Korndoerfer brought next idea : >> That'd be pretty dumb, to ask a compiled component whether it's running in >> the IDE, wouldn't it? Maybe I don't understand the objection. > > I can think of several purposes: > > - a tools dll that is used by your applications and contains for your > convenience as one of the tools the IsInIDE function. Here the tools dll > (which is supposed to be used compiled also during application development) > should report True, when the *application* that uses it is running in the > IDE. Using the Debug.Assert trick then is not the way to go. Shoot the designer. Should've known better. Sounds useful, sure, until you ponder the fact it's entirely useless given the design! > - the dll on its own needs to differentiate wether it is running compiled or > not (typically when the dll uses subclassing). Here the dll uses its IsInIDE > function itself and so the function then should report True when the dll > itself is running uncompiled in the IDE (because it is in a project group > with the application that uses it). Different case, and that would work correctly, if I understand. I was talking about calling this Compiled() function from an external module (as in EXE/DLL, not BAS/CLS/FRM). > Btw it is easier to simply check the return value of > GetModuleHandle("VBA6.dll"). This dll is loaded in the process space (at > least if not the user's code loaded it) only when the app is running in the > IDE. Easier I may not agree with, but then I didn't see the original suggestion. Anyway, yeah, that's a great way to go for those DLL situations. That also let's you restrict operations to just in the IDE or EXE, should you so wish. Of course, you'd want to allow for VB5 usage, too. > So it depends on the use case wether for IsInIDE functionality the > Debug.Assert way or the Api way is used. > > Or did now I misunderstand you? I don't think you should be asking this question of a module outside your own. You don't know what circumstances it's in, and you shouldn't. It's just one of those blackbox lines we cross at our own peril. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Ulrich Korndoerfer on 28 Jan 2010 22:57
Hi, Karl E. Peterson schrieb: > Ulrich Korndoerfer brought next idea : >>> That'd be pretty dumb, to ask a compiled component whether it's >>> running in the IDE, wouldn't it? Maybe I don't understand the >>> objection. >> >> I can think of several purposes: >> >> - a tools dll that is used by your applications and contains for your >> convenience as one of the tools the IsInIDE function. Here the tools >> dll (which is supposed to be used compiled also during application >> development) should report True, when the *application* that uses it >> is running in the IDE. Using the Debug.Assert trick then is not the >> way to go. > > Shoot the designer. Should've known better. Sounds useful, sure, until > you ponder the fact it's entirely useless given the design! > But it is useful. When I develop applications or dlls, and each of them must know wether it runs in the IDE, I could either: - include the same code (using Debug.Assert) again and again in each of them - or use my compiled tools dll and ask the tools dll wether the app or dll currently developed runs in the IDE. Supposed that they would anyway need a reference to the tools dll because they need some of the other tools in there, including the IDE thing would be handy, or not? >> - the dll on its own needs to differentiate wether it is running >> compiled or not (typically when the dll uses subclassing). Here the >> dll uses its IsInIDE function itself and so the function then should >> report True when the dll itself is running uncompiled in the IDE >> (because it is in a project group with the application that uses it). > > Different case, and that would work correctly, if I understand. I was > talking about calling this Compiled() function from an external module > (as in EXE/DLL, not BAS/CLS/FRM). > >> Btw it is easier to simply check the return value of >> GetModuleHandle("VBA6.dll"). This dll is loaded in the process space >> (at least if not the user's code loaded it) only when the app is >> running in the IDE. > > Easier I may not agree with, but then I didn't see the original > suggestion. Rather clumsy. I cite from the original post: Private Function IsInIDE() As Boolean Dim hModule As Long, lLen As Long Dim strModule As String * 256 'Initialize the string. strModule = Space$(255) hModule = GetModuleHandle(vbNullString) lLen = Len(strModule) iLen = lLen 'Get the module name. GetModuleFileName hModule, strModule, iLen 'Return the result. IsInIDE = (UCase$(Trim$(strModule)) Like "*VB6.EXE*") End Function Anyway, yeah, that's a great way to go for those DLL > situations. That also let's you restrict operations to just in the IDE > or EXE, should you so wish. Of course, you'd want to allow for VB5 > usage, too. > I do not have experience with VB5, but I think he mechanism is the same and the file name should be changed to VBA5.dll. >> So it depends on the use case wether for IsInIDE functionality the >> Debug.Assert way or the Api way is used. >> >> Or did now I misunderstand you? > > I don't think you should be asking this question of a module outside > your own. You don't know what circumstances it's in, and you > shouldn't. It's just one of those blackbox lines we cross at our own > peril. > -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/ |