I have an Access database that is located in my Google Drive folder hierarchy, with the Google Drive Windows 10 app synchronising with my Google cloud storage.
I've managed to muck something up.
I used to be able to open the same file (separately) on 2 PCs and let the app synchronise changes in the cloud.
But now, the Access database application runs fine on one PC, but gives an error of
"there was an error compiling this function"
when the autoexec macro runs.
looking at the code - the syntax error is in this declaration (which used to be fine)
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Macros also will not run unless I enable all macros in the trust centre settings.
I have added the containing folder to the trusted folders, but still it persists.
If I copy the accdb file to my documents folder on the problematic PC it misbehaves there too.
Both PCs have are running Windows 10 and Office 365. All patching up to date I think.
It has me baffled.
Any help greatly appreciated.
I installed the 64 bit version of Office on the other PC and changed the declaration to:
#If VBA7 Then
Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As LongPtr)
#Else
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End If
Everything is working now.
Related
I am trying to link a dll to a vba project and I am going nut 'cause it fails to find it even if I am 100% sure of the path (I pasted 100 times the path from the exact position).
I called
Private Declare Function IMB_connect _
Lib "C:\Users\Andrea.GIORDANO\Desktop\API\bin_dynamic\API.dll" _
(ByVal n As String) As Long
But it continues to return me an error 53: File not found.
I don't get what would be the problem that seems so silly...
I tried with all kind of slashes '\', '\', '/', '//': no success.
FYI I linked the same exact dll within a c++ project and in that case worked well so I believe the dll itself is fine...
Your dll is probably dependent on other dlls. You can use Dependency Walker to get the full list of the dependent dlls.
The dependent dlls must be in one of the following (from msdn):
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the
path of this directory.
The 16-bit system directory. There is no function that obtains the
path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable.
Note that this does not include the per-application path specified
by the App Paths registry key. The App Paths key is not used when
computing the DLL search path.
If you are running a VBA project, probably Excel.exe is loading your code. This means the dependent dlls of your API.dll must be in one of the directories in the quote above.
Please note that placing dlls in the system directory could affect the functionality of other applications in the system. (read about dll hell).
I am trying to make a copy of this directory from my program and when I try it tells me that, "the path does not exist".
If your application is a 32-bit app on a 64-bit system then you're experiencing what's called File system redirection.
Because 32-bit apps cannot load 64-bit dlls, and 64-bit apps cannot load 32-bit dlls, a 64-bit system has two system folders:
System32 - the 64-bit version with 64-bit dlls, and:
SysWOW64 - the 32-bit version with 32-bit dlls.
The File System Redirector automatically redirects %SystemRoot%\System32 to %SystemRoot%\SysWOW64 for all 32-bit apps trying to access the System32 folder, so the reason you cannot copy the directory is because it doesn't exist in the SysWOW64 folder.
There are three ways you can overcome this. I've listed them in the order where the first is the most recommended, and the last is the least recommended:
Use the SysNative folder instead.
Instead of C:\Windows\System32 you can use C:\Windows\SysNative which will take 32-bit apps to the original System32 folder.
If Environment.Is64BitOperatingSystem = True AndAlso Environment.Is64Process = False Then 'Is this a 32-bit app in a 64-bit system?
My.Computer.FileSystem.CopyDirectory("C:\Windows\SysNative\spp\store", "your destination path here")
Else 'This is either a 64-bit app in a 64-bit system, or a 32-bit app in a 32-bit system.
My.Computer.FileSystem.CopyDirectory("C:\Windows\System32\spp\store", "your destination path here")
End If
Compile your app in 64-bit mode or AnyCPU.
Disable File System Redirection by P/Invoking the Wow64DisableWow64FsRedirection() function. (I really do not recommend this as things might break if your app tries to load dlls from the system directory).
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
My.Computer.FileSystem.CopyDirectory("C:\Windows\System32\spp\store", "D:\store", True)
End Sub
I've made an application that gets installed/deployed to /Program Files/STUDYvault/ called "STUDYvault Client.exe" and in the app, a button triggers/calls a .cmd that's in the same directory, called 'Scripts System.cmd'
Private Sub SynchroniseToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles MenuBackup.Click
System.Diagnostics.Process.Start("SCRIPTS SYSTEM.cmd")
End Sub
The .CMD just runs basic xcopy commands for backups. When the software is executed manually, it sees the .cmd within the same directory, however, when it is run by the system (eg startup, either by registry key or via shortcut in the startup folder) (I tried both Inno Setup AND NSIS), it crashes with an Unhandled Exception, 'Cannot find the file specified'. I'm thinking the OS is executing the .exe but running it in say /Windows or /System32 or something. It doesn't seem to be an issue with the visual studio app (it runs when executed manually, and finds the .cmd no matter what the directory) or the installer (it's basically just extracting to /Program Files and putting a link in the startup part of the registry)
My friend and I thought up a workaround, although it's quite nefarious. One could force the user to install the software to C:/Program Files/STUDYvault and have it unchangeable, and then in the app have it point to C:/Program Files/STUDYvault/Scripts System.cmd instead of just "SCRIPTS SYSTEM.cmd" - could this work also?
I'm sure I'm just missing something stupidly small, because the application fires the following code fine when installed:
Private Sub HivemindTechToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles HivemindTechToolStripMenuItem.Click
System.Diagnostics.Process.Start("http://my-website.com.au")
End Sub
EDIT:
Alright, I've developed a work-around for anyone having this issue. It seems to be rights-related or where the system is executing it from; so it's calling on the .CMD from wherever that is (most likely not its install directory) - so in-app I've had it call on:
Private Sub SynchroniseToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles MenuBackup.Click
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\STUDYvault\\SCRIPTSYSTEM.cmd")
End Sub
Which is the install directory, and then in the installer (Inno Setup) I've used the following for defining the install directory under [setup]:
DefaultDirName={sd}\Program Files (x86)\STUDYvault
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
DisableDirPage=yes
Here, DefaultDirName=SD\DIRECTORY defines that it will be force-installed to Program Files (x86) (Fine for 64-bit Windows users, 32-bit users will have to deal with a second Program Files folder but x64 is the most common install in this day and age anyway so we won't have an issue there); DisableDirPage=yes hides the install page that asks the user where they want to install it - most users will leave it as-is but for the more curious user who may want to change it, this WILL break the install, seeing as it's calling on /Program Files (x86)/STUDYvault in-app.
It's a relatively dirty fix, and I feel like Dr. Evil here, but ...it works. Hopefully this will help anyone having a similar issue in the future.
Use this
Process.Start(Application.StartupPath & "\SCRIPTSYSTEM.cmd")
You can get location of the executable file by using Environment.CurrentDirectory. Using this property we can make the code works regardless of executable folder location (as long as cmd file exist in the same folder, of course). So this maybe a more proper way to get the job done :
Dim batchFilePath As String = Path.Combine(Environment.CurrentDirectory, _
"SCRIPTS SYSTEM.cmd")
System.Diagnostics.Process.Start(batchFilePath)
You may want to improve it further by adding logic to check if cmd file actually exist in the location pointed by batchFilePath (you can use System.IO.File.Exists() to do that).
I use unrar lib on Mac OS. I can't unrar bundles inside archive. I have a bundle - Mybundle.component inside the archive. During extracting the files I come across, say, the file like
MyArchive/Mybudle.component/Contents/myfile.file
which I need to place by path
/Users/MyUser/Unarchived/Mybudle.component/Contents/myfile.file
For this purpose I use RARProcessFile. It works if /Users/MyUser/Unarchived/Mybudle.component exists. How can I "extract bundle"?
I have added COM control AxWindowsMediaPlayer to form in vb.net.
and just have following code
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
WMPlayerVideo.URL = "abase.mp4"
End Sub
End Class
abase.mp4 file is kept in directory where exe is there. Every thing runs fine on dev m/c but on client machine application is not lauached.
When Interop.WMPLib.dll and Interop.WMPLib.dll are copied to the exe file directory then application is lauched at least but file is not played automatically and even on pressing play button its not played.
Is some dll registration required to make it work? or some references needed in project?
or some changes on user machine?
Copying the DLLs is required, it cannot work otherwise. Which leaves the location of the file. You are only giving the relative location of the file, not the full path (like "c:\mumble\foo.mp4"). On your machine, this file needs to be stored in the bin\Debug folder of your project directory to make it work. Another machine you deploy your program to isn't going to have a bin\Debug (or Release) folder. It still needs to be present in the same directory as the EXE. Maybe you forgot to copy the .mp4 file?
Clearly you'll want to provide the user with a way to select the file. Use OpenFileDialog.