Damn I really geek out when I do some cool programming routines
The J2534 DLLs are basically unmanaged libraries where you p/invoke the functions to be able to use them.
What happens here, is the actual J2534 DLL isn't consumed in a normal manner, and can struggle to work out 'where' any of its external dependencies may be.
For example, I required several files not part of the standard .netframework library, so when these DLLs are to be used, it does not know where to look for the DLL and will throw an error saying it cannot find it and crashing the application.
The solution sounds kinda obvious, but its not something thats very documented or used for that matter. Basically the application can be setup to capture the error in an event which offers the chance to load the required dependency in. Which this ability, we can store our required dependency DLL as an embedded resource and then load manually. What makes this cool, is the fact that every single DLL used could be stored internally which ensures that no missing DLLs ever occur (antivirus deleting or file moved).
Anyways, it is a big step forward here. The OBDX Pro Remote Programmer panel is less fancy then the client one, but this was simply due to trying to reduce the resources I needed to consume from the above issue.
I have tried to keep this as simple as humanly possible, there is literally 4 steps:
1) Enter client session ID to connect
2) License scantool if you have not already
3) When ready to proceed with the J2534 software, click the giant button labelled "click to proceed with J2534 Application Session".
I have added the last step so that a programmer can provide instructions to a client first before proceeding with the session such as turn ignition off/on, or inform them if their battery voltage is too low.
Otherwise situations such as a custom not having the ignition on can occur.
Remote6.png
You do not have the required permissions to view the files attached to this post.
