I use the objSNMP.get method in Excel VBA without any problems.
I'd like to use the objSNMP.set method, but unfortunately it's not that easy. According to the website, it should work similarly to get, with the difference that there is one more parameter: the value to be sent.
If I try the official way:
objSNMP.Set ("43.18.1.1.2", OIDValue)
Image1
I get the message "Compile error: Syntax error".
I found another solution that works conditionally. Namely as follows (it can be seen commented out in the picture):
randomVarName = objSNMP.Set("OID", Value)
For example:
temp = objSNMP.Set(".1.3.6.1.4.1.9.9.68.1.2.2.1.2." & PortNum, 21)
In this case, the code runs without error. This is interesting because I haven't found any official information about this anywhere. Somewhere deep in the recesses of the internet, I only found this possible solution some time ago.
If, on the other hand, I do not enter the value directly, but write the name of a variable there (e.g. VLANNum),
temp = objSNMP.Set(".1.3.6.1.4.1.9.9.68.1.2.2.1.2." & PortNum, VLANNum)
I receive an error message. Image2
It doesn't matter if the type of the variable is not declared, string or integer. I also tried several different cell types in Excel, but nothing changed.
The error message is:
Run-time error '-2147467259 (80004005)':
The requested SNMP operation attempted to modify a variable, but
either a syntax or value error occurred.
Based on the above, I cannot insert the value read from the excel table at the end of the "objSNMP.Set" method in such a way that it can send the value. I could only solve the task if I create 4094 different "objSNMP.Set" lines and select what is necessary from among them. Not very efficient.
I have the solution. The value transferred with the variable works in the following form:
objSNMP.Set ".1.3.6.1.2.1.2.2.1.7.9", CInt(x)
Where x is the variable.
A bit of a trivial question, but it got my interest.
I often edit my code on the fly, or in other words, when in debug mode. I do this so I can quickly check the edits I have made for performance.
When in debug mode, one can neither remove nor alter Dim statements without countering the warning message:
This action will reset your project, proceed anyway?
I assume this is due to the compiler having stored variables in the memory in a manner specific to their data types, something which presumably can't be altered while the code is 'running'.
I have noticed, however, that adding a declaration in break mode can be done without any issues. Trying to remove or edit this line then once again throws the warning message.
Why is it possible to add but not to remove/edit declarations in break mode?
I strongly assume that the VBA runtime prevents you from modifying existing entries in the symbol table. Consider you have done something like
Dim i as Integer
i = 3
Debug.print i
You set a breakpoint to the Print-statement and change the type of i to String - what should the runtime do with the content of i? Implicitly convert it to a String? And what should happen if a conversion is not possible?
Adding a new entry into the symbol table doesn't do any harm because it doesn't modify anything that was done previously, so the runtime allows you to do so.
Btw: If you remove Option Explicit (I know you & me never do this...) and assign a value to an (undeclared) variable: This variable is now put into the symbol table and if you try to add a Dim-statement now, you will get the This action will reset...-message.
It appears that if you open a Workbook that declares even a single Public Function in its project with the 'Notify Before State Loss' VBE option enabled, VBE will prompt you with the "This action will reset your project, proceed anyway?" message as soon as you attempt altering the declaration line of this function. Probably because Excel somehow "loads" a variable that will hold the returned value...
I have a VBA function that worked fine, until I tried to pass an extra variable to it. Now the code won't run, and I get an error stating Expected:=, I've tried renaming the function, but no help.
Was - Function GetData(site_add)
Changed to Function GetData(site_add, temporary) and failed - despite changing the call to the function accordingly...!?!
Is it possible that the compiler is glitching and I should focus on that? I have other functions in the code that use 5 call 5 variables and don't even call/use them all...!? Help...
By adding the second parameter, you are effectively telling the compiler that every call to this method now requires two parameters instead of one. So you have to find everywhere you call the GetData() function and make sure it now passes two parameters instead of one, even if the second parameter is Nothing. Now, if you want it to default to nothing so you don't need to pass it you can rewrite it as
GetData(site_add, Optional temporary)
*my vb is rusty, so take my example with a grain of salt please.
I'm having some trouble automating a matlab script which should prompt the user for the variable they are interested in, as well as the date range they want. I then want the script to concatenate their answers within a naming convention for the file they will ultimately load.
variable=input('please input variable of interest');
% temp
start=input('please state the start date in the form yymmdd: ');
%130418
enddate=input('please state the end date in the form yymmdd: ');
%140418
file=sprintf('%s_dailydata_%d_%d.csv',variable,start,enddate);
%so I thought 'file' would look like: temp_dailydata_130418_140418.csv
vardata=load(file);
the two numbers representing the dates are not causing any issues, but the fact that 'variable' is a string is. I know if I put apostrophes before and after 'temp' when I'm promted, it will work, but I have to assume that the end user won't know to do this. I tried putting curly braces around 'please input your variable..', but that didn't help either. Obviously this approach assumes that the date being requested exists in a filename.
Can anyone offer any advice? Perhaps the sprintf function is not the best option here?
Don't use 'end' as a variable name, it is a reserved name and using it could create conflicts with any function or logic block you're defining.
If you know your input is going to be a string: from the documentation for input()
str = input(prompt,'s')
Returns the entered text as a MATLAB string, without evaluating expressions.
As for knowing whether or not the file exists, that's something you'd have to incorporate some error logic for. Either a try/catch block with your load() call or you could use uigetfile() to get the filename.
Q. Excel keeps throwing the following error, whenever my addin is loaded (Runtime Error 49, Bad DLL calling convention)
The dialog starts to pop up everytime with no indication of where the error is, despite having absolutely no external DLL references.
OR
Q. Excel crashes every time I save a particular line of code.
How can this be fixed?
This error is probably occurring because of a compiler-bug.
The easiest solution to this, would be to make a small code-change and recompile.
What I usually do is,
1 -> Add a Private Enum type to the top of any module in the addin
Private Enum Something
member = 1
End Enum
2 -> Compile the addin
3 -> Restart excel
4 -> Remove the code change made. It is no longer necessary.
Even though this error refers to an external (DLL) function call, it
can be triggered by a parameter or return-value type mismatch for a
VBA-defined function or subroutine. Furthermore, when it is
triggered by these causes, the debugger sometimes displays the error
point to be a different function call, often higher in the
call-stack, including calls that have been working and stable until
the problem-situation was created. Often, the problem is triggered
by a miss-match between a fixed-type parameter-argument or return value and a
Variant or vice versa.
Example: A Variant-valued function returns a
Long value at run time that is assigned to an Integer variable.
Resolution:
Carefully check all parameter-argument and return
value types and assignment statements, especially for routines that
you have been recently working on. If any are Variant-valued functions, explicitly type-cast to the correct type for the
assignment.
If the above situation is unavoidable due to using the Application.Run method to call a routine in a different workbook (for which you have no control over the parameter definitions), as a result of the Application.Run method passing all arguments ByVal, then, if the containing routine is a Sub, try converting it to a Function with no specified return type. This seems to force a clean-up of the stack and suppresses the error condition being thrown at a higher level in the call-stack.
An object method (such as AutoFit) applied to an erroneous object variation for which that method isn’t available (such as AutoFit
being applied to a range that is neither an entire row or entire
column range). Similarly to the above scenario, the error may be
thrown at the return point of the routine in which the problem
statement exists, not at the statement itself.
Resolution: Start with fixing the
syntax problem. Unfortunately fixes that should work sometimes
continue to throw the error until the VBE editor is reset. I
haven’t deduced the minimal set of steps that resolve that issue but
something like this often works:
Explicit recompile the project.
Save the file and close it.
Re-open the file and re-run the code.
If a call to an external library function is identified as the culprit, refer to Microsoft’s documentation on the error:
Bad DLL calling convention
*Arguments passed to a dynamic-link library (DLL) must exactly match
those expected by the routine. Calling conventions deal with number,
type, and order of arguments. Your program may be calling a routine
in a DLL that is being passed the wrong type or number of arguments.
To correct this error make sure all argument types agree with those
specified in the declaration of the routine that you are calling.
Make sure you are passing the same number of arguments indicated in
the declaration of the routine that you are calling.
If the DLL routine expects arguments by value, make sure ByVal is
specified for those arguments in the declaration for the routine.
Return argument:
One thing that can be easily overlooked when
talking about procedure arguments is the return argument. Make sure
its of the correct type, or that its not missing. Excel/VBA users
are used to the fact that if you leave out a return type for a
function, the system implicitly sets the return type to Variant, and
it works with any returned data. Not so with externally declared
functions!! The return type has to be declared in the DECLARE
statement.*
Broken library references: check whether the library references for your module code are valid. In the VBA IDE, select
Tools=>References to see the list of referenced libraries and make
sure none of the checked items are marked "Missing". If so, fix
those.
Or, the best option ever:
- Rewrite the name of the routine.
- Then recompile !
You're good to go now!
For info, I also experienced "Runtime Error 49, Bad DLL calling convention" in Excel VBA code that had been running fine.
The error was pointing to an internal function call and the fix for me was to change an argument from ByVal to ByRef. There existed a call to another function where that value was already passed ByRef, so this may have been a factor.
Another way instead of "change/add something and recompile" would be to /decompile your project.
Esp. in large access/excel projects that can get ride of a lot of problems.
Just to add another possible cause, I was using the Application.OnTime method to call a public sub with a parameter. The parameter is meant to be a long (the current row), but I'm guessing it's actually passed as a string value.
Here is an example of the OnTime call:
Application.OnTime Now + TimeValue("00:00:01"), "'UpdateEditedPref " & curRow & "'"
I tried performing an arbitrary update to the code and recompiling, but this didn't fix the issue. What fixed it was changing the parameter type from long to string in the called sub:
Public Sub UpdateEditedPref(ByVal inRowStr As String)
Then you just need to convert the string to a value within the sub. Thankfully, no more error.
Update: Passing a parameter using Application.OnTime seems to have caused another error, "Cannot run the macro". I was getting this error when the worksheet was locked. I'm still using Application.OnTime, but instead of passing a parameter, I'm saving the value in a global variable and using that value in the called sub. This now appears to be working correctly.
The OnTime call now looks like this:
' Set global variable
gCurRow = curRow
Application.OnTime Now + TimeValue("00:00:01"), "UpdateEditedPref"
I had a similar issue, on my development PC it was working just fine. Funny thing was I had two separate calls to the same routine, one worked and the other didn't. On a production PC, kept getting the error. Tried renaming the routine, changing the parameters, parameter types to no avail.
What worked for me was to move the failing calling routine into the same module as the called subroutine.
The routine that was working previously was already in the same module.
In my case this was "caused" by an excessive use of the continue character _ in a single if conditional
I had already recompiled, checked all return codes, moved modules around ,restarted excel , restarted my computer, copied the code to a brand new Excel spread-sheet, I read this article and the bit about return codes made me think about how many returns can be in an if statement
I had this
If CompressIntoOneLineON(rg1, rgstart, rgend) or _
CompressIntoOneLineOS(rg1, rgstart, rgend) or _
CompressIntoOneLineOGN(rg1, rgstart, rgend) or _
CompressIntoOneLineOGS(rg1, rgstart, rgend) or _
CompressIntoOneLineGO(rg1, rgstart, rgend) Then
<code>
End If
I was getting the error when the subroutine containing this code exited
So I changed to this
matched = True
If CompressIntoOneLineON(rg1, rgstart, rgend) Then
ElseIf CompressIntoOneLineOS(rg1, rgstart, rgend) Then
ElseIf CompressIntoOneLineOGN(rg1, rgstart, rgend) Then
ElseIf CompressIntoOneLineOGS(rg1, rgstart, rgend) Then
ElseIf CompressIntoOneLineGO(rg1, rgstart, rgend) Then
Else
matched = False
End If
if matched then
<code>
and the error went away
My experiments have shown:
The error: 'Runtime Error 49, Bad DLL calling convention' disappeared when I replaced the declarations:
Dim coll as new Collection
on
Dim coll as Collection
Set coll = New Collection
The object must explicitly become Nothing on failure of creation (if it does not itself) so that its existence can be traced.
Thanks, RubberDuck VBA