I have a VB6 application that, despite everything manages to work on lots of systems, including the numerous Windows 7 x64 systems.
On most of them, the windows dialogs accessed through COMDLG32.OCX work just fine. However, on one particular system, this doesn't work at all. Some forms, when attempting to show the "Open" (or "Save") dialog causes an exception:
Run-time error '32765'
The common dialog function failed during initalization. This error often occurs when insufficent memory is available
Although some other forms that use it simply never show the dialog box at all. Needless to say, memory is not an issue. Microsoft have a kb article on the error where they say:
You have a Microsoft Visual Basic 6.0 program that runs on a Terminal Server, the program uses the Common Dialog control to open a file, and the following conditions are true:
The user is using a roaming profile.
There is a policy to delete the roaming profile when the user logs off.
When these conditions are true, you may receive [the error quoted above]
The conditions mentioned are not true - this is all through the (only, local) user on the system. The suggested solution involves calling the relevant API calls directly.
Reluctant to implemenet the pile of code suggested in every form relevant, I found a class already built for the purpose - CDlgEx. While this works fine on all the computers where the OCX also works fine, on the system which has problems, whenver this line is reached:
RetValue = GetOpenFileName(OFN)
where
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long
and OFN is of the private type expected by the function, nothing happens. No dialog box appears, and the program simply moves on to the next line.
Further testing has shown that this only happens when running from the IDE. Running from a compliled executable, everything is fine.
Had the exact same problem. Grab the cCommonDialog class from the following link and add it to your project.
https://github.com/ziggythehamster/ignitionserver/blob/master/vbtracer/cCommonDialog.cls
You can then do something like this in your code
Private Sub Command1_Click()
Dim commonDialog As New GCommonDialog
Dim fileName As String
commonDialog.VBGetOpenFileName fileName
MsgBox fileName
End Sub
Related
Background:
Recently, a macro I use via VBA (in Excel) to run a script has stopped working; this subroutine worked for the previous six years. This is on a work device in which I do not have full admin privileges. The script file is stored on a network drive which I have access to, and can open and double-click to execute.
I have read from multiple sources, each not having an answer (including here on SO), that people have begun to see RTE5 when using Shell(), which may be related to security settings from the administrator.
One suggestion was to use use ShellExecute, which I have not had luck using.
Issue:
I receive RTE5 (invalid procedure call or argument) on the line for Shell() within the below code.
Question:
Has anyone had this same issue and been able to resolve said issue? Please indicate how you resolved.
Code:
'To open file, which previously worked:
Dim Loc As String
Loc = "Z:/filename.bat"
Call Shell(Loc, 1)
'Attempt at using ShellExecute, which gives Network Access error
Dim Loc As String
Loc = "Z:/filename.bat"
Call CreateObject("Shell.Application").ShellExecute(Loc, 1)
I have a very complex excel macro workbook. The VBA code seems to run pretty well on PC's at my location. As soon as I send it to a German colleague it fails to run in unexpected locations of the code.
The last problem I came across is a Runtime error 5 when the code try to modify the Caption of a UserForm (and some text boxes and cmd buttons as well).
Previously we faced with the same issue with SlicerCache(x).ClearManualFilter but somehow I healed itself...
My first thought was to break up the nest With and see which row causes the fail, but it's immediately the first row. I assume it'll do the same for all rows.
I have checked the windows and office settings:
I'm running Win10, English language settings and Hungarian formatting settings. -> Code running well.
My local colleagues run the same system with Hungarian language and formatting. -> Code running well.
The problematic colleague runs Win10 with German language and formatting settings. -> Code fails to run.
We both have the same Reference libraries in VBA editor, none missing. (I assume it's carried by the excel file itself.)
I have Microsoft 365 MSO (16.0.13801.21050) 32-bit, he running 16.013801.21004 32-bit. (I suppose the update scheduled by the IT department.) This portion of code months before my latest office update, so I don't think it's a cause.
The sub called by a CommandButton_Click event, and calls the user form zurueckExport. The form is deisgned so that can called for differnet purposes, so the captions have to be modified according to the needs.
I have ran out of ideas, don't see what and why cause it. Does anybody could give me some help to deal with this issue? I would be very glad.
Public Sub verExport()
With zurueckExport
.Caption = "Version Exportieren zum Creo"
.Label1.Caption = "Welche Version möchten Sie zum Creo exportieren?"
.CommandButtonExportieren.Visible = True
.CommandButtonZurueckladen.Visible = False
.CommandButtonKennlinie.Visible = False
.KennlinieFormat.Visible = False
.Show
End With
End Sub
The captions were too long, that generated the error message on the other computer.
Resolution:
I have added several different labels to the UserForm and modify their visibility instead of overwrite the caption.
Many thanks for #J0eBl4ck for the idea.
This is a weird error. It only occurs on some machines here, but not all of them. Furthermore, I researched this website and there are no solutions that I can see that cover this.
I receive this error when attempting to run some VBA code in an excel document.
The line of code it occurs in is in the
Private Sub UserForm_Initialize()
event.
The line of code is:
Set objTest = CreateObject("MTRClassLibrary.MTRTestComClass")
As I mentioned previously, the code only errors out on some of the machines here but not all of them.
It is not clear where and how the objTest instance is declared in the code. Also, you need to make sure the corresponding object is registered on the problematic machine. The CreateObject can't locate applications with ProgId passed as a parameter. Try to check the Windows registry for the string passed.
See Object variable not set (Error 91) for all possible cases.
Somehow I get a problem, if I call an application twice or several times but only one instance should be running (which is desired).
First some (probably necessary) background information:
working on MAC OS X El Capitan (10.11.6)
I've got an Application made by node.js, electron and build by "npm build -m" (let's call it APP.app)
I installed the application App.app into program-folder by opening the built dmg-file and move it into the program-folder
Then I start the application App.app by click on the App.app-icon in program-folder
The application starts with a visible Window and also has an hidden background process running
If I close the visible Window, the App.app-Icon remains in the dock (which is okay, since the background-process is still running)
Now (and this is the difference to the windows build and running in windows), if I click again on the App.app-Icon in the program-folder, I only get a focus on the already running application INSTEAD of opening the window and close the old application (I can see te focus switch/activation by the switching menu name beside the apple-logo on top of the screen; it becomes "App")
the closing of the previous running instance is defined in electron code in the init-method as follows:
var shouldQuit = app.makeSingleInstance(function (commandLine, workingDirectory) {
console.info('starting new instance');
initInternal(commandLine);
// Someone tried to run a second instance, we should focus our window.
var windows = options.closeWindowsOnRestart ? Browser.getAllWindows() : appWindows.slice();
windows.forEach(function (val, index) {
val.close();
});
readyCallback();
});
So, I did some homework and could figure out following:
my App.app-icon-click should look something like open /Applications/App.app
with this, I get the same problem as descriped above if I call it again (it only focusses the already opened window)
Now comes the funny part. If I open the application by calling directly /Applications/App.app/content/MacOS/App.app the old application-instance is closed and new App.app-application is started
I read through open-manual and could figure out, that if I use the -n-flag, the application starts succesful a new instance, too. (open /Applications/App.app -n)
I was wondering WHY? Do you have any clues? What is the difference between open and directly call of the application?
I suggest that the info.pklist in App.app-package is making the open-call different to the direct call of App.app.
BTW:
Unfortunately I already tried to add try-catch-blocks to debug the problem, but open does not give an output to terminal, it just opens the call whereas the direct call does not throw an error and everything works fine.
Anyway, I believe it's more a MAC OS X problem than an App.app-problem.
Hopefully there's somebody with same problems and a solution for me
Don't hesitate to ask for more details, if needed.
Short Version:
open starts the application with the LaunchService (and possible
added launch-parameters in info.plist)
whereas direct call of the
application just starts the application iself without any other
launch-options
*Long Version *
I read through the open manual (man open; Source: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/open.1.html) and could figure out, that "the default application as determined via LaunchServices is used to open the specified files" if you click on an item.
So I read through the LaunchService-documentation and could figure out following:
"Opening Items by File-System Reference [...] default way:
If the designated item is an application: [...]
If the application is already running, it is activated (brought to the front of the screen) and sent an 'rapp' (“reopen
application”) Apple event."
(Source: https://developer.apple.com/library/content/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCTasks/LSCTasks.html#//apple_ref/doc/uid/TP30000999-CH203-TP9)
This reflects exactly my watching that if I click on the icon the second time, the app is just focussed/activated.
Thus I need the possibility to tell the application to open a new instance (oapp-event) instead of activating the already opened application (rapp-event)
Further reading lead me to following informations:
"Launch Options When opening an application (whether by itself or to
open one or more documents or URLs), you can specify various launch
options to control the manner in which it is launched or activated.
These can include: [...] Whether to launch a new instance of the
application, even if another instance is already running"
(Source: https://developer.apple.com/library/content/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html#//apple_ref/doc/uid/TP30000999-CH202-BABBJHID)
Thus I only need to add the "launch option" to define, that a new instance should be created instead of activating the existing one. But there's not written what the launch-option for it is and how they will be applied to the application (I suggest it belongs into info.plist-file).
So at least this is the answer to my original question, so I posted it here.
open - starts the application with the Launch-Service (and the defined option-parameters in info.plist)
whereas direct call of the application just starts the application iself without any other launch-options
First three elements of the background:
I have created a Excel Template which is used, in turn, to create a 'personalised template' where user name, user comment, and save data pathnames are embedded in the personalised template.
The personalised template is used to produce monthly workbooks (actually, time sheets)
The template has been created in Office/Excel 2007 running under Vista but the (current) target environment is a corporate network running Office/Excel 2003 under XP Professional. Both templates are therefore created as Excel 2003 templates (which in the development environment run in compatibility mode)
So far, so good - the templates work well in the development environment - the 'personalisation' code is in a WorkBook_Open() routine under 'ThisWorkbook' - it runs, DELETES ITSELF, and saves as the personalised template. Both templates have the 'process macros' in the Sheet1 code (the principle here is that the initial template has macros in 'ThisWorkbook' and 'Sheet1'; the personalised template has macros only in 'Sheet1' and the workbooks created from the personalised template have NO MACROS AT ALL.
In 'beta testing' I had problems with Excel2000 under XP (fileformats) and on a target machine my WorkBook_Open routine was deleted in the main template (instead of in the personalised template) - even though everything worked OK on Excel2007/Vista.
I felt at the time that the invalid deleting of Workbook_Open was probably a coding error -but whilst researching the issues I found a number of references to 'Macafee deleting VBA modules'. I did not look into these - but was conscious that the target machine (and environment) run Macafee whilst all my computers run Norton.
Having recoded, I successfully retested in the following:
a) Excel 2007/Vista/Norton
b) Excel 2007/XP Professional/Norton
c) Excel 2000/XP Home/Norton
so felt comfortable to re-test in Excel 2003/XP Professional/Macafee
This time I was watching for it - so, once again, saw the WorkBook_Open routine incorrectly deleted from the main template - unfortunately this was only moments before the USB Memory Key (where the template was running from) was completely destroyed.
So to the question(s) - before I go through the whole process again:
Is there any objective evidence of Macafee removing 'auto-run' VBA modules?
If yes, is there any work-around (this template will be use by three people in a enterprise of ten thousand - so there is no way I will be able to influence/modify the security policies!!! :( ) - if there is a problem with Macafee then I will have to re-think the whole thing!
To answer your actual question... YES, many antivirus programs absolutely consider autorun code that runs on opening Excel or Word docs to be unsafe, and deletes it, because for a brief moment ten years ago this was actually the way some worms worked. I don't know if MacAfee in particular does this but I've definitely heard of it happening.
JUst in case anyone else comes to this thread - I have now fully checked out my template - and re-run it in the target environment - and the Workbook_Open routine was again deleted. after doing some digging around on the target machine I found the Macafee event log and lo and behold...
Event Type: Warning
Event Source: McLogEvent
Event Category: None
Event ID: 258
Date: 09/07/2011
Time: 15:45:40
User: NT AUTHORITY\SYSTEM
Computer:xxxxxxxxxx
Description:
The file F:\Timesheets\Timesheet Generator.xlt\1.OLE contained X97M/Generic Virus. The file was successfully cleaned with Scan engine version 5400.1158 DAT version 6400.0000.
So there is the definitive proof.
Same thing happens with Workbook_Activate()
The 'offending' lines appear to be
With ThisWorkbook.VBProject.VBComponents("ThisWorkbook").CodeModule
.DeleteLines 1, _
.CountOfLines
I have managed to get to the client machine again - and added a new simple template to prove or otherwise my issue. The new WorkBook_Open routine is...
Private Sub WorkBook_Open()
MsgBox "Hello World"
With ThisWorkbook.VBProject.VBComponents("ThisWorkbook").CodeModule
.DeleteLines 1, _
.CountOfLines
End With
MsgBox "Goodbye to all that!"
End Sub
...and this works exactly as required i.e. the routine executes then deletes itself (the second msgbox displays even though the code has been deleted!
So, this test invalidates my question - McAfee is NOT deleting the routine as part of AV protection - so I am no longer looking for a workaround!
Now all I need to do is to figure out what my problem really is!
Thanks for the comments