I'm trying to write a subroutine in access 2003 that removes all quote characters from strings in an array. The subroutine removes the quotes successfully in the routine itself, but not when the program returns to the passing function. I'm very confused, as it is done ByRef.
How it is called:
Call removeQuotes(wbs_numbers())
and the subroutine itself:
'goes through a string array and removes quotes from each element in the array'
Sub removeQuotes(ByRef string_array() As String)
For Each element In string_array()
'chr(34) is quotation character. visual basic does not have escape characters.'
element = Replace$(element, Chr(34), "")
Next
End Sub
Can someone please explain what I am doing wrong? I would love you forever!
Your array may be by reference, but element isn't. Iterate by index, and set the string back into the array once you've manipulated it.
You are creating new variable "element" and do not store it back in string_array, so it is not changing.
My VB is a little rusty but a quick google search turned up something like this:
Dim i As Integer
For i = LBound(string_array) To UBound(string_array)
string_array(i) = Replace$(string_array(i), Chr(34), "")
Next
Related
I have written a version control module. The AutoExec macro launches it whenever I, or one of the other maintainers log in. It looks for database objects that have been created or modified since the previous update, and then adds an entry to the Versions table and then opens the table (filtered to the last record) so I can type in a summary of the changes I performed.
It is working great for Tables, Queries, Forms, Macros, etc but I cannot get it to work correctly for modules.
I have found two different properties that suggest a Last Modified date ...
CurrentDB.Containers("Modules").Documents("MyModule").Properties("LastUpdated").Value
CurrentProject.AllModules("MyModule").DateModified
The first one (CurrentDB) always shows "LastUpdated" as the Date it was created, unless you modify the description of the module or something in the interface. This tells me that this property is purely for the container object - not what's in it.
The second one works a lot better. It accurately shows the date when I modify and compile/save the module. The only problem is that when you save or compile a module, it saves / compiles ALL the modules again, and therefore sets the DateModified field to the same date across the board. It kind of defeats the purpose of having the DateModified property on the individual modules doesn't it?
So my next course of action is going to a bit more drastic. I am thinking I will need to maintain a list of all the modules, and count the lines of code in each module using VBA Extensions. Then, if the lines of code differs from what the list has recorded - then I know that the module has been modified - I just won't know when, other than "since the last time I checked"
Does anyone have a better approach? I'd rather not do my next course of action because I can see it noticeably affecting database performance (in the bad kind of way)
Here's a simpler suggestion:
Calculate the MD5 hash for each module.
Store it in the Versions table.
Recalculate it for each module during the AutoExec and compare it to the one in the Versions table. If it's different, you can assume it has been changed (while MD5 is bad for security, it's still solid for integrity).
To get the text from a module using VBE Extensibility, you can do
Dim oMod As CodeModule
Dim strMod As String
Set oMod = VBE.ActiveVBProject.VBComponents(1).CodeModule
strMod = oMod.Lines(1, oMod.CountOfLines)
And then you can use the following modified MD5 hash function from this answer as below, you can take the hash of each module to store it, then compare it in your AutoExec.
Public Function StringToMD5Hex(s As String) As String
Dim enc
Dim bytes() As Byte
Dim outstr As String
Dim pos As Integer
Set enc = CreateObject("System.Security.Cryptography.MD5CryptoServiceProvider")
'Convert the string to a byte array and hash it
bytes = StrConv(s, vbFromUnicode)
bytes = enc.ComputeHash_2((bytes))
'Convert the byte array to a hex string
For pos = 0 To UBound(bytes)
outstr = outstr & LCase(Right("0" & Hex(bytes(pos)), 2))
Next
StringToMD5Hex = outstr
Set enc = Nothing
End Function
You can't know when a module was modified. The VBIDE API doesn't even tell you whether a module was modified, so you have to figure that out yourself.
The VBIDE API makes it excruciatingly painful - as you've noticed.
Rubberduck doesn't deal with host-specific components yet (e.g. tables, queries, etc.), but its parser does a pretty good job at telling whether a module was modified since the last parse.
"Modified since last time I checked" is really all you need to know. You can't rely on line counts though, because this:
Option Explicit
Sub DoSomething
'todo: implement
End Sub
Would be the same as this:
Option Explicit
Sub DoSomething
DoSomethingElse 42
End Sub
And obviously you'd want that change to be picked up and tracked. Comparing every character on every single line of code would work, but there's a much faster way.
The general idea is to grab a CodeModule's contents, hash it, and then compare against the previous content hash - if anything was modified, we're looking at a "dirty" module. It's C#, and I don't know if there's a COM library that can readily hash a string from VBA, but worst-case you could compile a little utility DLL in .NET that exposes a COM-visible function that takes a String and returns a hash for it, shouldn't be too complicated.
Here's the relevant code from Rubberduck.VBEditor.SafeComWrappers.VBA.CodeModule, if it's any help:
private string _previousContentHash;
public string ContentHash()
{
using (var hash = new SHA256Managed())
using (var stream = Content().ToStream())
{
return _previousContentHash = new string(Encoding.Unicode.GetChars(hash.ComputeHash(stream)));
}
}
public string Content()
{
return Target.CountOfLines == 0 ? string.Empty : GetLines(1, CountOfLines);
}
public string GetLines(Selection selection)
{
return GetLines(selection.StartLine, selection.LineCount);
}
public string GetLines(int startLine, int count)
{
return Target.get_Lines(startLine, count);
}
Here Target is a Microsoft.Vbe.Interop.CodeModule object - if you're in VBA land then that's simply a CodeModule, from the VBA Extensibility library; something like this:
Public Function IsModified(ByVal target As CodeModule, ByVal previousHash As String) As Boolean
Dim content As String
If target.CountOfLines = 0 Then
content = vbNullString
Else
content = target.GetLines(1, target.CountOfLines)
End If
Dim hash As String
hash = MyHashingLibrary.MyHashingFunction(content)
IsModified = (hash <> previousHash)
End Function
So yeah, your "drastic" solution is pretty much the only reliable way to go about it. Few things to keep in mind:
"Keeping a list of all modules" will work, but if you only store module names, and a module was renamed, your cache is stale and you need a way to invalidate it.
If you store the ObjPtr of each module object rather than their names, I'm not sure if it's reliable in VBA, but I can tell you that through COM interop, a COM object's hashcode isn't going to be consistently consistent between calls - so you'll have a stale cache and a way to invalidate it, that way too. Possibly not an issue with a 100% VBA solution though.
I'd go with a Dictionary that stores the modules' object pointer as a key, and their content hash as a value.
That said as the administrator of the Rubberduck project, I'd much rather see you join us and help us integrate full-featured source control (i.e. with host-specific features) directly into the VBE =)
I thought I would add the final code I came up with for a hash / checksum generation module, since that was really the piece I was missing. Credit to the #BlackHawk answer for filling in the gap by showing that you can late bind .NET classes - that's going to open up a lot of possibilities for me now.
I have finished writing my Version checker. There were a few caveats that I encountered that made it hard to rely on the LastUpdated date.
Resizing the columns in a Table or Query changed the LastUpdated date.
Compiling any Module compiled all modules, thus updated all module's LastUpdated date (as was already pointed out)
Adding a filter to a form in View mode causes the form's Filter field to be updated,which in turn updates the LastUpdated date.
When using SaveAsText on a Form or Report, changing a printer or display driver can affect the PrtDevMode encodings, so it is necessary to strip them out before calculating a checksum
For Tables I built a string that was a concatenation of the table name, all field names with their size and data types. I then computed the hash on those.
For Queries I simply computed the hash on the SQL.
For Modules, Macros, Forms, and Reports I used the Application.SaveAsText to save it to a temporary file. I then read that file in to a string and computed a hash on it. For Forms and Reports I didn't start adding to the string until the "Begin" line passed.
Seems to be working now and I haven't come across any situations where it would prompt for a version revision when something wasn't actually changed.
For calculating a checksum or hash, I built a Class Module named CryptoHash. Here is the full source below. I optimized the Bytes Array to Hex String conversion to be quicker.
Option Compare Database
Option Explicit
Private objProvider As Object ' Late Bound object variable for MD5 Provider
Private objEncoder As Object ' Late Bound object variable for Text Encoder
Private strArrHex(255) As String ' Hexadecimal lookup table array
Public Enum hashServiceProviders
MD5
SHA1
SHA256
SHA384
SHA512
End Enum
Private Sub Class_Initialize()
Const C_HEX = "0123456789ABCDEF"
Dim intIdx As Integer ' Our Array Index Iteration variable
' Instantiate our two .NET class objects
Set objEncoder = CreateObject("System.Text.UTF8Encoding")
Set objProvider = CreateObject("System.Security.Cryptography.MD5CryptoServiceProvider")
' Initialize our Lookup Table (array)
For intIdx = 0 To 255
' A byte is represented within two hexadecimal digits.
' When divided by 16, the whole number is the first hex character
' the remainder is the second hex character
' Populate our Lookup table (array)
strArrHex(intIdx) = Mid(C_HEX, (intIdx \ 16) + 1, 1) & Mid(C_HEX, (intIdx Mod 16) + 1, 1)
Next
End Sub
Private Sub Class_Terminate()
' Explicity remove the references to our objects so Access can free memory
Set objProvider = Nothing
Set objEncoder = Nothing
End Sub
Public Property Let Provider(NewProvider As hashServiceProviders)
' Switch our Cryptographic hash provider
Select Case NewProvider
Case MD5:
Set objProvider = CreateObject("System.Security.Cryptography.MD5CryptoServiceProvider")
Case SHA1:
Set objProvider = CreateObject("System.Security.Cryptography.SHA1CryptoServiceProvider")
Case SHA256:
Set objProvider = CreateObject("System.Security.Cryptography.SHA256Managed")
Case SHA384:
Set objProvider = CreateObject("System.Security.Cryptography.SHA384Managed")
Case SHA512:
Set objProvider = CreateObject("System.Security.Cryptography.SHA512Managed")
Case Else:
Err.Raise vbObjectError + 2029, "CryptoHash::Provider", "Invalid Provider Specified"
End Select
End Property
' Converts an array of bytes into a hexadecimal string
Private Function Hash_BytesToHex(bytArr() As Byte) As String
Dim lngArrayUBound As Long ' The Upper Bound limit of our byte array
Dim intIdx As Long ' Our Array Index Iteration variable
' Not sure if VBA re-evaluates the loop terminator with every iteration or not
' When speed matters, I usually put it in its own variable just to be safe
lngArrayUBound = UBound(bytArr)
' For each element in our byte array, add a character to the return value
For intIdx = 0 To lngArrayUBound
Hash_BytesToHex = Hash_BytesToHex & strArrHex(bytArr(intIdx))
Next
End Function
' Computes a Hash on the supplied string
Public Function Compute(SourceString As String) As String
Dim BytArrData() As Byte ' Byte Array produced from our SourceString
Dim BytArrHash() As Byte ' Byte Array returned from our MD5 Provider
' Note:
' Because some languages (including VBA) do not support method overloading,
' the COM system uses "name mangling" in order to allow the proper method
' to be called. This name mangling appends a number at the end of the function.
' You can check the MSDN documentation to see how many overloaded variations exist
' Convert our Source String into an array of bytes.
BytArrData = objEncoder.GetBytes_4(SourceString)
' Compute the MD5 hash and store in an array of bytes
BytArrHash = objProvider.ComputeHash_2(BytArrData)
' Convert our Bytes into a hexadecimal representation
Compute = Hash_BytesToHex(BytArrHash)
' Free up our dynamic array memory
Erase BytArrData
Erase BytArrHash
End Function
I have files in one folder with following naming convention
ClientID_ClientName_Date_Fileextension
12345_Dell_20110103.CSV
I want to extract ClientID from the filename and store that in a variable. I am unsure how I would do this. It seems that a Script Task would suffice but I am do not know how to proceed.
Your options are using Expressions on SSIS Variables or using a Script Task. As a general rule, I prefer Expressions but mentally, I can tell that's a lot of code, or a lot of intertwined variables.
Instead, I'd use the String.Split method in .NET. If you called the Split method for your sample data and provided a delimiter of the underscore _ then you'd receive a 3 element array
12345
Dell
20110103.CSV
Wrap that in a Try Catch block and always grab the second element. Quick and dirty but of course won't address things like 12345_Dell_Quest_20110103.CSV but you didn't ask that question.
Code approximate
string phrase = Dts.Variables["User::CurrentFile"].Value.ToString()
string[] stringSeparators = new string[] {"-"};
string[] words;
try
{
words = phrase.Split(stringSeparators, StringSplitOptions.None);
Dts.Variables["User::ClientName"].Value = words[1];
}
catch
{
; // Do something with this error
}
I'm in the process of a code review and have come across this:
Dim lngLen As Long
lngLen = 16&
I have done some reading and it appears to be that this is a way of casting the number to a long - is that correct?
But is that really necessary here as you can just assign lngLen the value of 16 because it's a numeric value.
Also, following this code this is done:
Dim strCompName As String
strCompName = String$(lngLen, 0&)
I realize the String method, from the Access help definitions, "returns a variant containing a repreating character string of the length specified."
So what does the $ do? And again is the & casting the 0 to a long?
Hi you can check this question for a possible answer to your query.
Edit:
Moreover, I was able to scour the internet for more resources and I found this VBA typing convention which originally found on this forum page.
Hopefully this would help you.
Well as per you inquiry
Some people think Choosing the function that returns the correct type will be slightly more efficient and this makes faster executing code.
Well on the other hand some thinks It serves no useful
purpose at all to add the type declaration suffix in the code when it was
not declared with the suffix. Surely that does nothing but obfuscate the
code.
String$ is a function
The $ at the end is a way of declaring the variable As String.
The & at the end is a way of declaring the variable As Long.
You are right i dont think these are necessary here.
I'm trying to write a VBScript and I'm using functions such as Randomize, and MsgBox. I'm curious as to what is the difference of using () and not using them. For example:
Randomize - This line works.
Randomize() - This line works also.
MsgBox "Hello, World!" - This works.
MsgBox ("Hello, World!") - This works as well.
The script will be running on multiple machines with different versions of Windows (at least Windows XP). I'm wondering if I would be getting any compatibility/syntax issues in using these functions.
A callable piece of code (routine) can be a Sub (called for a side effect/what it does) or a Function (called for its return value) or a mixture of both. As the documentation for MsgBox,
Displays a message in a dialog box, waits for the user to click a
button, and returns a value indicating which button the user clicked.
MsgBox(prompt[, buttons][, title][, helpfile, context])
indicate, this routine is of the third kind.
The syntactical rules of VBScript are simple:
Use parameter list () when calling a (routine as a) function
If you want to display a message to the user and need to know the user's response:
Dim MyVar
MyVar = MsgBox ("Hello, World!", 65, "MsgBox Example")
' MyVar contains either 1 or 2, depending on which button is clicked.
Don't use parameter list () when calling a (routine as a) Sub
If you want to display a message to the user and are not interested
in the response:
MsgBox "Hello, World!", 65, "MsgBox Example"
This beautiful simplicity is messed up by:
The design flaw of using () for parameter lists and to force call-by-value semantics
>> Sub S(n) : n = n + 1 : End Sub
>> n = 1
>> S n
>> WScript.Echo n
>> S (n)
>> WScript.Echo n
>>
2
2
S (n) does not mean "call S with n", but "call S with a copy of n's value".
Programmers seeing that
>> s = "value"
>> MsgBox(s)
'works' are in for a surprise when they try:
>> MsgBox(s, 65, "MsgBox Example")
>>
Error Number: 1044
Error Description: Cannot use parentheses when calling a Sub
The compiler's leniency with regard to empty () in a Sub call. The 'pure'
Sub Randomize (called for the side effect of setting the random seed) can be called by
Randomize()
although the () can neither mean "give me your return value) nor "pass
something by value". A bit more strictness here would force programmers to be aware of the difference in
Randomize n
and
Randomize (n)
The Call statement that allows parameter list () in Sub calls:
>> s = "value"
>> Call MsgBox(s, 65, "MsgBox Example")
which further encourage programmers to use () without thinking.
(Based on What do you mean "cannot use parentheses?")
To my knowledge, these are the rules for calling subroutines and functions in VBScript:
When calling a subroutine or a function where you discard the return value, don't use parentheses
When calling a function where you assign or use the return value, enclose the arguments in parentheses
When calling a subroutine using the Call keyword, enclose the arguments in parentheses
Since you probably won’t be using the Call keyword, you only need to learn the rule that if you call a function and want to assign or use the return value you need to enclose the arguments in parentheses. Otherwise, don't use parentheses.
Here are some examples:
WScript.Echo 1, "two", 3.3 - calling a subroutine
WScript.Echo(1, "two", 3.3) - syntax error
Call WScript.Echo(1, "two", 3.3) - keyword Call requires parentheses
MsgBox "Error" - calling a function "like" a subroutine
result = MsgBox("Continue?", 4) - calling a function where the return value is used
WScript.Echo (1 + 2)*3, ("two"), (((3.3))) - calling a subroutine where the arguments are computed by expressions involving parentheses (note that if you surround a variable by parentheses in an argument list it changes the behavior from call by reference to call by value)
WScript.Echo(1) - apparently this is a subroutine call using parentheses, but in reality, the argument is simply the expression (1), and that is what tends to confuse people that are used to other programming languages where you have to specify parentheses when calling subroutines
I'm not sure how to interpret your example, Randomize(). Randomize is a subroutine that accepts a single optional argument, but even if the subroutine didn't have any arguments, it is acceptable to call it with an empty pair of parentheses. It seems that the VBScript parser has a special rule for an empty argument list. However, my advice is to avoid this special construct and simply call any subroutine without using parentheses.
I'm quite sure that these syntactic rules applies across different versions of operating systems.
You are just using a single parameter inside the function, hence it is working fine in both the cases, like follows:
MsgBox "Hello, World!"
MsgBox ("Hello, World!")
But when you'll use more than one parameter, in VBScript a method with parentheses will throw an error and without parentheses will work fine like:
MsgBox "Hello, World!", vbExclamation
The above code will run smoothly, but
MsgBox ("Hello, World!", vbExclamation)
will throw an error.
Try this!! :-)
You have to distinguish between subroutines and functions in VBA... Generally (as far as I know), subroutines do not return anything and the surrounding parentheses are optional. For functions, you need to write the parentheses.
As for your example, MsgBox is not a function but a subroutine and therefore the parentheses are optional in that case. One exception with functions is, when you do not assign the returned value, or when the function does not consume a parameter, you can leave away the parentheses too.
This answer goes into a bit more detail, but basically you should be on the save side, when you provide parentheses for functions and leave them away for subroutines.
I inherited this old TurboBasic code base, and I am converting it to something more modern.
Can you explain how in this code snippet Wind can be both a variable and an array?
Dim Wind(1:3,2:3)
Sub WindFunction
Shared Wind()
local var
Erase Wind
Wind = 123
var = Wind
Wind(1,2) = 567
End Sub
The wikipedia page on Turbo Basic suggests that it is one of the dialects where
A ... double
A$ ... string
A(...) ... array of double
are treated as totally separate variables, so in your case you have
Wind(...) ... an array of double
Wind ... a double
These dialects treat most variables' types just by their name. Only arrays need to be declared. Sometimes even arrays can be addressed without declaration, they are then assumed to be an array with one dimension and a size of 10.
Some more links can be found here on SO (oh, just saw it's by you, too *g*):
https://stackoverflow.com/questions/4147605/learning-turbobasic