Motorola MC65 - EMDK .NET 2.6 - E_SCN_READTIMEOUT using ScanWait() - motorola-emdk

I'm looking to integrate the Barcode2 class in the EDMK 2.6 library into our existing Barcode scanning interface.
I've wired the example code up to our interface method StartScan() and always get E_SCN_READTIMEOUT as the result even though the code seems to be responding to the scan. (the breakpoint at if (scan.Result == Results.SUCCESS) is hit in response to the scan
public void StartScan()
{
if (!barcode.IsScanPending)
{
ScanData scan = barcode.ScanWait(2000); // 2 second timeout
if (scan.Result == Results.SUCCESS)
{
if (scan.IsText)
{
textbox1.Text = scan.Text;
}
}
}
}
The result is always E_SCN_READTIMEOUT, I suspect this may be a conflict with DataWedge 3.4 running on the device, but the functionality of the scanner and triggers seem to be dependent on it.
Getting barcode scans to the clipboard using DataWedge is not an option for us, is there a way to get the library to function despite DataWedge(assuming that is causing the read timeouts)?

The DataWedge application did need to be disabled, (this can be done programmatically via the datawedge API from Motorola, Thanks Abdel for the hint here!).
https://docs.symbol.com/ReleaseNotes/Release%20Notes%20-%20DataWedge_3.3.htm
A little background on our Windows Mobile application for reference, we have a hardware singleton that contains interfaces for all hardware components and loads related types and assemblies via reflection. If we referenced types directly the code above worked.
The end solution ended up being to use the Symbol.Barcode library instead of Symbol.Barcode2.

Related

Is it possible to use pyobjc with a privilved XPC helper tool and XPCInterface API?

I believe the answer to this question is "no", but I'm putting it out to the community just in case someone has been more successful than I have.
I have a privileged helper tool that a client Cocoa application uses with the NSXPCConnection and NSXPCInterface. The interface itself includes a method that provides a return code through a completion handler block.
In Objective-C the client code looks like this:
NSXPCConnection * xpcConn = [NSXPCConnection alloc]
initWithMachServiceName:kSvcName
options:NSXPCConnectionPrivileged];
// MyProtocol defines an instance method runCommand:(NSString*) withReply:^(int result)
NSXPCInterface * mySvcIF = [NSXPCInterface interfaceWithProtocol:#protocol(MyProtocol)];
xpcConn.remoteObjectInterface = mySvcIF;
[xpcConn resume];
if (nil == xpcConn.remoteObjectProxy) {
NSLog(#"ERROR - remote interface is nil, can't communicate with service");
}
[[xpcConn remoteObjectProxy] runCommand:nsstrCmd withReply:^(int result) {
NSLog(#"service result is: %d", result);
if (result != 0) {
self.svcResult = result;
self.svcCommandComplete = YES;
}
}];
I also have a pyobjc / py2app Mac application that needs to use this helper tool's functionality. I've got the tool built into the pyobjc app bundle, signed, and authorizing via SMJobBless, but it is looking like there are several problems that make actual use of this API unsupported:
1) Bridging the invocation of runCommand:withReply:^ doesn't seem to be supported - if I understand correctly blocks are only supported for NS* framework method invocations not for 'custom' (i.e. user-defined) methods? Note, I could make a version of the method with no return code if this was the only blocking issue, but an attempt didn't quite work because...
2) In order to use the API in the way the Objective-C does I need to create a #selector reference to runCommand: that does not actually have any python function implementation - it needs to just be a function object that defines the signature for a function that will be furnished by the dynamically created remoteProxy. I don't define the remoteProxy implementation in python. This does not seem to be supported - I could not get the selector declaration without a python function to work via objc.selector().
3) I'm not positive that even if I could get 2) to work, that construction of the formal protocol would work the way it's expected to as a parameter to interfaceWithProtocol: from python - it needs to become a native custom #protocol that NSXPCInterface could use in its factory method to create the remoteProxy.
Thanks for any tips if you've figured out how to do this in pyobjc, or any definitive confirmation that this stuff just isn't possible based on your knowledge of it.
The first two subquestions are straightforward to answer: It is possible to call APIs with blocks, even those in libraries that aren't Apple frameworks. This does require some more work in the python code because the Objective-C runtime doesn't expose enough information to fully automatically do the right thing.
For this particular example you could do something like this:
objc.registerMetaDataForSelector(b'NSObject', b'runCommand:withReply:', {
'arguments': {
3: {
'callable': {
'retval': {'type': b'#'},
'arguments': {
0: {'type': b'^v'},
1: {'type': b'i'},
},
},
}
}
})
This registers additional information for the method "-[NSObject runCommand:withReply:]". The block argument is number 3: counting starts at 0 and the first two arguments of Objective-C methods are "self" and "_sel" (the latter is not exposed to Python).
You normally use the actual class where the method is implemented, but I expect that this is a hidden class that might even be dynamically generated. Just registering metadata on NSObject should be safe as long as there is no conflict with other classes.
Creating protocols in Python is also possible:
MyProtocol = objc.formal_protocol('MyProtocol', (), [
objc.selector(None, b"runCommand:withReply:", signature=b"v#:##?"),
])
And creating the XPC interface with:
mySvcIF = Foundation.NSXPCInterface.interfaceWithProtocol_(MyProtocol)
The latter step sadly enough does not work because NSXPCInterface raises an exception: NSInvalidArgumentException - NSXPCInterface: Unable to get extended method signature from Protocol data (MyProtocol / runCommand:withReply:). Use of clang is required for NSXPCInterface..
I've filed an issue for this in PyObjC's tracker: https://github.com/ronaldoussoren/pyobjc/issues/256.
A workaround for this issue is to create a Python extension that contains the protocol definition as well as an unused function that uses the protocol (see for example https://github.com/ronaldoussoren/pyobjc/blob/415d8a642a1af7f2bd7285335470098af4962dae/pyobjc-framework-Cocoa/Modules/_AppKit_protocols.m for the latter part). After importing the extension you can use objc.protocolNamed("MyProtocol") to access the protocol, which will then refer to the full protocol object created by clang and should work with NSXPCInterface.
This solution is now documented in the official documentation, here: https://pyobjc.readthedocs.io/en/latest/notes/using-nsxpcinterface.html
P.S. I rarely visit stackoverflow, its often easier to get my attention by mailing to pyobjc-dev#lists.sourceforge.net (PyObjC mailinglist).

Which handle should I use to initialize my scanner app

I wish to operate a scanner using a windows service hosting a web API.
The reason I am doing so is to be able to operate the scanner from javascript using ajax and I do not wish to use ActiveX.
So I built a Windows Service hosting a Web API.
I tried for the web API to start a scan application (had to bypass the UAC for this) but I run into a consistency issue (sometimes it worked and sometimes not).
So for now the controller of the web API has the code to start scanning built into it (instead of an external application). The problem is that I don`t have a handle to give the twain wrapper (it needs it for the windows message hook).
I tried to take the current process MainWindowHandle and even tried something silly as taking iexplore MainWindowHandle and I get an exception "Error initialising DSM".
As a twain library I use TwainDotNet
The code for doing is:
var p = Process.GetCurrentProcess();
_twain = new Twain(new WinFormsWindowMessageHook(p.MainWindowHandle));
Any idea on a good way to get a handle that will work? as I wrote above I ok with "stealing" another application handle if that will do the job (e.g. iexplore)
The exception is thrown from the TwainDotNet class DataSourceManager constructor in this code:
TwainResult result = Twain32Native.DsmParent(
ApplicationId,
IntPtr.Zero,
DataGroup.Control,
DataArgumentType.Parent,
Message.OpenDSM,
ref windowHandle);
if (result == TwainResult.Success)
{
...
}
else
{
throw new TwainException("Error initialising DSM: " + result, result);
}
Thanks
Well I found an answer to this one.
I used an ApplicationLoader class code from this URL.
The code I use to get the good handle is:
var processes = Process.GetProcessesByName("iexplore");
if (processes.Length == 0)
{
WriteToLog("ScanController.Run GetProcessesByName returned 0 processes. Something went wrong!!!");
return "ScanController.Run Failed: counlt not get handle to perform scan";
}
var p = processes[0];
var hProcess = ApplicationLoader.OpenProcess(ApplicationLoader.MAXIMUM_ALLOWED, false, (uint)p.Id);
Hope this will help someone.

Vertex Array Objcects - glGenVertexArrays GL_INVALID_OPERATION on OSX

I'm trying to get a simple OpenGL program going, but I can't get it to display anything. I'm using Swift on a Mac, neither of which I am familiar with, although I've got a good amount of experience with OpenGL on windows. The program runs fine (no GL errors or anything), but nothing displays, until I add this at the end of my openGL initialization:
var vao:GLuint=0;checkGlError();
glGenVertexArrays(1, &vao);checkGlError();
glBindVertexArray(vao);checkGlError();
Then, it gives GL_INVALID_OPERATION as soon as I call glGenVertexArrays(), however the docs don't mention that as an option.
I worried that I might not have a GL3 context (and really I'd prefer to just have a GL1/2 context, however the Swift headers seem to be missing things like glBegin() and glColor3f(), so I decided to settle for GL3), so I tried to manually request one:
required init?(coder: NSCoder) {
super.init(coder: coder);
let attribs=[NSOpenGLPFAOpenGLProfile,NSOpenGLProfileVersion3_2Core,0];
pixelFormat=NSOpenGLPixelFormat(attributes: UnsafePointer<NSOpenGLPixelFormatAttribute>(attribs));
openGLContext=NSOpenGLContext(format: pixelFormat, shareContext: nil);
openGLContext.view=self;
openGLContext.makeCurrentContext();
};
However this didn't seem to affect things at all.
First, glBegin (...) is not valid in a core profile context. You are going to need a legacy (non-core) context for that.
Now, since the legacy context is limited to OpenGL 2.1, it only offers GL_APPLE_vertex_array_object. In a 2.1 context, you can call glGenVertexArraysAPPLE (...) and glBindVertexArrayAPPLE (...) and they will do the same thing.
The problem you are encountering is that on OS X, you link to the same framework regardless which context version you get. That means that you can call functions that are not supported by your context at run-time. Any time you try to use a GL 3.2+ function from the legacy context, you get GL_INVALID_OPERATION.
I was able to solve this by creating a bridging header and including #include in that, then using a GL1 context.

Language Service: ParseReason.Check never called after migrating to VS2010

I just migrated my language service from VS2008 to VS2010. Everything works fine except for one important thing: I no longer get LanguageService.ParseSource invoked for ParseReason.Check. It do get a single invoke after opening a file. But after editing code, it no longer gets invoked.
Any ideas what could be causing that?
I also migrated a language service from 2008 to 2010. Can you check if you've fallowed all of these steps?
http://msdn.microsoft.com/en-us/library/dd885475.aspx
I didn't have to do anything else, which I verified by diffing the important files in our depot before and after the change.
I don't know if you ever figured your question out, but have you tried making sure that your Source class' LastParseTime is set to 0 when creating it? I seem to recall some issues with Check not happening unless you manually set LastParseTime to 0 when creating your Source object.
Protip: If you use .NET Reflector, you can disassemble all of the base classes for the LanguageService framework and get a pretty good understanding of how it all works under the hood. The classes you'd be interested in live in Microsoft.VisualStudio.Package.LanguageService.10.0.dll, which should be installed in the GAC. I've found this to be unimaginably helpful when trying to figure out why things weren't working in my own Language Service, and being able to step through the source code in the debugger mitigates almost all the pain of working with these frameworks!
When your Source object is initialized, it starts off with a LastParseTime of Int32.MaxValue. The code that causes fires off a ParseRequest with ParseReason.Check checks the LastParseTime value to see if the time since the last change to the text is less than the time it takes to run a parse (or the CodeSenseDelay setting, whichever is greater).
The code that handles the response from ParseSource is supposed to set the LastParseTime, but as far as I can tell, it only does that if the ParseReason is Check.
You can get around this issue by setting Source.LastParseTime = 0 when you initialize your Source. This has the side-effect of setting CompletedFirstParse to true, even if the first parse hasn't finished yet.
Another way to fix this issue is to override Source.OnIdle to fire off the first call to BeginParse() This is the way I would recommend.
public override void OnIdle(bool periodic)
{
// Once first "Check" parse completes, revert to base implementation
if (this.CompletedFirstParse)
{
base.OnIdle(periodic);
}
// Same as base implementation, except we don't check lastParseTime
else if (!periodic || this.LanguageService == null || this.LanguageService.LastActiveTextView == null || (this.IsCompletorActive) || (!this.IsDirty || this.LanguageService.IsParsing))
{
this.BeginParse();
}
}

Is there a way to prevent Visual Studio from breaking on exceptions in a specific method?

I know I can control the way Visual Studio handles exceptions according to their type and to the fact that they're eventually caught using the "Exception" dialog.
However, I've got a library that's internally throwing (and catching) an ArgumentOutOfRange exception when I'm calling a specific method. The exception is thrown (and caught by the library) maybe 1% of the time, but I'm calling this method a lot. The editor says it's by design (and indeed, the design they've chosen makes sense).
The thing is that I don't want Visual Studio to break each time the exception is thrown.
I don't want to stop breaking on ArgumentOutOfRange exceptions, as I may have some in my code and want to break on those.
I don't want to enable "just my code" debugging because I'm concerned about the exceptions thrown outside of my code (notably for performance reasons)
Is there a way to achieve this? I've been looking into attributes (such as DebuggerStepThrough), but haven't find something adequate yet.
Any hints on how to do this ?
I don't want to enable "just my code" debugging
Yeah, stop there right now. That is exactly the feature you need to not get the unwanted debugger breaks. If you don't want to know about somebody else's crappy code then flip that checkbox back on.
This invariably goes off the rails when programmers use exceptions for flow control. A very common crime. It takes two of them to turn that into a mess that turns a debugging session into a very tedious click nightmare. When you need the debugger feature that breaks on the first-chance exception then you basically lost if somebody else needed that as well.
Everybody hopes that they can magically use the [DebuggerNonUserCode] or [DebuggerHidden] or [DebuggerStepThrough] attributes to make that problem disappear. It doesn't. The other programmer did not think his code was unimportant enough to deserve those attributes. And, well, it wasn't because there's always a bug hidden in code that uses try/catch-em-all code. Pokémon code.
So Microsoft had to find another way to help programmers deal with crappy library code. They did. Tick that checkbox, bam, solved. Nothing you can do about that crappy code anyway, other than sending a nasty-gram to the author. Don't let us or Microsoft slow you down doing that as well, y'all have to get along to create a product that people like to use.
I think it's not possible in visual studio but it certainly is in WinDbg.
See for example http://blogs.msdn.com/b/alejacma/archive/2009/08/24/managed-debugging-with-windbg-breaking-on-an-exception-part-1.aspx
On a side note it seems that starting with visual studio 2010 you can load and use WinDbg extension DLLs directly providing aditional functionality (including possibly the one that you need) but I haven't tried this yet - see for example http://www.dotnetcurry.com/ShowArticle.aspx?ID=648
What you can do is use Concord, the debug engine that ships with Visual Studio (starting with version 2012). It's quite extensible through a nice managed API (and deployable using vsix technology), but it's not fully documented.
Concord has the concept of debug monitors, that we can hook using the IDkmDebugMonitorExceptionNotification Interface
The cool thing is this interface can monitor all exceptions thrown. It can also "suppress" any detected exception event, which is exactly what we need.
What I suggest is to start with the Hello World sample: . Download it, and make sure it runs as expected for you.
Now, just modify HelloWorld.vsdconfigxml like this:
<!--TODO: If you copy the sample, ensure to regenerate the GUID in this file -->
<!-- 1. change component level to something higher than 40500 -->
<ManagedComponent
ComponentId="51736b11-9fb4-4b6d-8aca-a10a2b7ae768"
ComponentLevel="40501"
AssemblyName="HelloWorld">
<!-- 2. change class full name to HelloWorld.ExceptionHandler, for example -->
<Class Name="HelloWorld.ExceptionHandler">
<Implements>
<InterfaceGroup>
<NoFilter/>
<!-- 3. change supported interface -->
<Interface Name="IDkmDebugMonitorExceptionNotification"/>
</InterfaceGroup>
</Implements>
</Class>
</ManagedComponent>
Then, just create an ExceptionHandler.cs class and put something like this in there:
public class ExceptionHandler : IDkmDebugMonitorExceptionNotification
{
private bool _unhandledDetected;
// we're being called!
public void OnDebugMonitorException(DkmExceptionInformation exception, DkmWorkList workList, DkmEventDescriptorS eventDescriptor)
{
if (_unhandledDetected)
{
// this will cause the program to terminate
eventDescriptor.Suppress();
return;
}
if (exception.ProcessingStage.HasFlag(DkmExceptionProcessingStage.Unhandled))
{
_unhandledDetected = true;
}
else if (exception.ProcessingStage.HasFlag(DkmExceptionProcessingStage.Thrown))
{
if (SuppressException(exception))
{
eventDescriptor.Suppress();
}
}
}
// should we suppress a thrown (1st chance) exception?
private bool SuppressException(DkmExceptionInformation exception)
{
// implement any custom logic in here, for example use the exception's name
if (exception.Name == typeof(ArgumentOutOfRangeException).FullName)
{
// for example, use the module (assembly) name
var clrAddress = (DkmClrInstructionAddress)exception.InstructionAddress;
var clrModule = clrAddress.ModuleInstance;
if (clrModule.Name == "TheUglyOne.dll")
return true; // we don't want this one!
}
return false;
}
}
When you run the project, you should see all exceptions being monitored (regardless of your 'just my code' and/or exception triggers settings), so what you just need to do is implement some logic to suppress the ones you really don't want to see. I've not checked but I suppose you could build your logic using custom attributes as the Dkm classes provide quite a lot of .NET metadata information.
Note: as you can see, there is some trickery to make sure the program will terminate normally.

Resources