Determine scanner architecture, flatbad or feeder, WIA - vba

I am trying to write a function (in VBA) that will scan a single page if the scanner has a flatbad architecture, or multiple if it has a feeder. I am using Windows Image Acquisition 2.0 on Windows XP. The following line of code reutrns an error:
MsgBox wiaScanner.Properties("3086").Value
In here you can see that property 3086 stands for Document Handling Capabilities. When I run it I get "ID not found". This worked fine on windows 7. I'm sure there's an alternative way for windows XP, I just couldn't find it.
Any ideas?
Thanks

Related

How are the message boxes and runtime error windows localized in VB .NET?

I'm working with VB .NET application and trying to find a working way of localizing dialogue boxes (invoked by InputBox function - localize Cancel button) and any Runtime error notifications.
I tried
Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo(culture)
Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo(culture)
and it works on my local machine, however on the virtual machine used for the testing and set up more closely to how the real workstations would be it doesn't seem to work: there are still Cancel buttons and runtime errors in English (OS is localized in English).
I however can't seem to find any significant differences between my local machine and the virtual machine.
Could there be anything else that I'm missing?
Is the approach I'm using for localization here correct in the first place?
Thanks.
You can not localize system dialogs (MessageBox.Show). Its language is always in system's language. You can not localize Framework exception messages too - it is dependent on installed .NET Framework Language Packs.

How can I program the speakerphone on a pocketpc running Windows Mobile 6.5?

Thanks to Josef who put me onto the right track for coding Windows Mobile 6.5 phone support.
I have found some more tricks which I would like to share. Yes, I know it is old technology, but there are many devices being sold that still run mobile 6.5. So: How can I program the speakerphone on a pocketpc running Windows Mobile 6.5 in .NET Compact Framework 3.5 in VB.NET?
This is very simple once you know how. You call the DLL file ossvcs, but this DLL file exports functions by ordinal numbers, not by names.
See http://msdn.developer-works.com/article/12376405/Reject+Call for more details. The code follows:
<DllImport("ossvcs.dll", EntryPoint:="#218")> _
Private Shared Sub setSpeaker(ByVal sValue As Integer)
End Sub
' Call setSpeaker(1) to turn on and setSpeaker(0) to turn off.
' If you set the speaker on when you create the line than it will always turn the speaker on for every call made

SHGetFileInfo causes Heap Corruption when using SHGFI_ICON

When I enable Page Heap for my process under test, it triggers an Access Violation which indicates to me some type of heap corruption has occurred when SHGetFileInfo is called.
The top of the call stack shows msvcr90!wcspbrk and walking down it shows COM-related items in ole32 until shell32 is reached where we call SHGetFileInfo.
From what I've found online, a common problem for weirdness using shell32 is not calling CoInitialize/CoInitializeEx first, but at this point CoInitializeEx() has already been called, and calling it immediately prior to the below code simply returns S_FALSE.
The below code is in our DLL which is PInvoked from .NET (the code is used to retrieve the icon used for a particular file):
SHFILEINFOW shfi;
memset(&shfi,0,sizeof(shfi));
SHGetFileInfoW(A2W("C:\\logfile.txt"),
FILE_ATTRIBUTE_NORMAL,
&shfi,
sizeof(shfi),
SHGFI_USEFILEATTRIBUTES
| SHGFI_ICON
);
(where logfile.txt is random text file on my root drive)
I've hard-coded the first parameter to a file on my machine for simplicity.
I'm using a 64-bit Windows OS, but the code is run in a 32-bit context. I get the same result if I use the narrow version of SHGetFileInfo.
If I disable Page Heap for my process, there is no problem.
When I don't use the flag SHGFI_ICON, the issue doesn't occur.
EDIT: #HansPassant requested I add a reproduceable sample, here's a link to a Visual Studio 2010 Win32 Console Application demonstrating the issue: sample

MS Access crashes when trying to close down a connection to Blackbaud's Raiser's Edge API

I am the IT department of a Non-Profit organization. I have a question today which might be too specialized for this forum and I hope I do not waste my time writing it up. We are using Blackbaud's 'Raiser's Edge' (RE) Software (written in VB6 and VB.net as far as I know) to keep track of our membership and donations. We have an MS Access application (have been using it since before we got RE) to process donations and for now I want to keep it and only do minor changes to adapt it to the new software.
The MS Access program is now doing a few calls to the RE API which work great. To login and establish a connection I have to create a new 'REAPI' object and use it for other API calls. That REAPI object has a method called: SignOutOnTerminate which needs to be set to TRUE when creating that object. It is supposed to kill all connections to RE once my application closes. There is no regular .close method.
Once I create the object I can do work as many times as I want and there is no problem at all as far as I can see.
However when trying to close the application or set the object to nothing (Set REAPI = Nothing) Access crashes immediately (It fades out and I get the message that Windows is looking for a solution to the problem. Then Access closes and restarts itself.)
It is more annoying and unprofessional then hindering production but I want to fix it.
The App was developed on Windows 7 64-bit with Access 2010 32-bit. It was tested on Windows XP with Office 2003 or 2007 machines (32-bit) and behaves the same way.
I have posted this problem already on 2 Blackbaud forums and tried a suggested a work around which did not work (kill the process with a shell command and then set the object to nothing). Hopefully I will get more answers soon.
I tried to just exclude the SignOutOnTerminate when creating the object. But got the same behavior.
I looked in the Event Manager --> Application Log and found the Crash. It reported that access crashed because of this dll: C:\Windows\System32\MSVBVM60.dll (It is actually located in the SysWos64 folder as it is a 32-bit application).
Looking up this error I found some suggestions to replace it with an earlier version of the dll, the one which ships with XP. I found a file and tried the suggestion but it still crashed. The error log reported the older version number as faulting so I registered it correctly.
I also created a case with Blackbaud but the rep did not know what the problem is and did not have MS Access installed. He is trying to get his support team to install it for him so he can test and investigate this error.
The last suspicion I have is that the API is causing the error and my code is fine.
But before I make this assumption and until I get my answer from Blackbaud I want to do a final check, but I have run out of ideas for further trouble shooting and resorted to pose this problem in this forum.
Any Ideas?
I realise that this is an old thread and if you have solved this by now then that is great. However this is a known issue with The Raiser's Edge API. If you use .NET with RE's API (which is COM based) there is definitely some resource that is not cleaned up properly. At one point I suspected that it was something to with making use of RE's graphical interface i.e. by calling the regular login method to log you into RE. However even if you log in to RE using the "as a server" method supplying the user name and password it still crashes on exiting the application.
We have an installer that sets up credentials in RE. The installer is in .NET and accesses the RE API. We now show a message just before the end of the application telling users to ignore the impending crash... Not a great solution by any means.

Delphi Clipboard and Graphics DCU's Missing

I have this weird thing that keeps happening when trying to use the following unit:
XLSReadWriteII 5
Every time I add one of their components to my form and compile it, it gives me the following error:
[dcc32 Fatal Error] Unit1.pas(16): F1026 File not found: 'C:\Users\Gordon\Documents\RAD Studio\Projects\grdi\Clipbrd.dcu'
This tells me that there is no DCU's in my API, no I get the same error on my windows 7 and my windows 8 pc's. Delphi was installed from the embarcadero website via their installer.
If I download a clipboard.dcu and .pas file and run it again it gives me the same error saying Graphics.duc is missing...
I have emailed the company Axolot Data (the creators of XLSReadWrite 5) with regards to this issue, they just keep telling me my API is corrupt, on both pc's??
However what I find strange is that their supplied samples run.
How can I fix this?
I think I have found a solution or reason this is happening.
XLSReadWrite 5 is a VCL component which references the VCL API, im using FMX.
The package was designed for VCL and not FMX but for some reason shows up in the FMX Units.
Strange but that might be my cause