I added my driver in wince 6.0 platform builder. It compiles sucessfully and added in nk.bin(i checked manully by open nk.bin in vs2005) also reg file contaning that driver enrty. I did below processure to add my driver.
Copy driver code into “$(_TARGETPLATROOT)\Files\MyDriver”
Add below line at “platform.bib”
MyDriver.dll $(_TARGETPLATROOT)\Files\MyDriver\MyDriver.dll NK SHK
Add below line at “platform.reg”
#include "$(_TARGETPLATROOT)\Files\MyDriver\MyDriver.reg"
But when I flash that, nk.bin. driver is not loaded on board. I checked with tool which help to check which driver loaded on board.
Does anyone have idea about that?
We have no idea what is in mydriver.reg, so if there's a problem there, or the resulting platform.reg, then that could be an issue.
There are a few ways to diagnose this problem. The first step would be to check ce.bib and platform.reg and make sure the expected entries are there. If the driver or it's registry entries are not ending up in the OS, that would cause a problem.
If that looks good, then there are two steps you can take.
Build a Debug version of the OS, copy the debug version of device.exe into the FLATRELEASEDIR of a Release build and call makeimg. This will give you a release build with a debug version of device.exe. Boot up and look at the debug messages for when it attempts to load the driver and look at the report of the failure.
Create a simple application that calls ActivateDevice and look at the return value from it. Outputting debug messages from the driver in DllMain and XXX_Init is usually helpful as well.
Related
When I compile a project in XE8 (with update 1), I get frequently a error that a file is missing, although the file is just available. And when I compile again, it is another file that is missing. It seems random. After a few compiles (sometimes more or less) I have build the project. And even at Run (F9) I sometimes get the error that a file is missing.
Like #Andrei Galatyn said at the end of his post, it will be solved when you delete your Android configuration in SDK versions. But I want to be able to develop with Android. What is the real problem?
I couldn't find a solution on the internet yet.
Is there a solution for this problem? Thanks in advance!
I have similar problem with Delphi XE8/XE7 at least at 3 different PCs (home PC, notebook, VMW-based virtual machine in office). All PCs are fast, all are SSD-based. Usually i get the error message when trying to build large project, for small projects errors are very rare (but happens time to time anyway). So i am quite sure that it is problem with Delphi. What i tried:
added src/dcu paths as exception to antivirus
disabled indexing of files in Windows (Windows 7 x64/Windows 8.1 x64)
deleted all SDKs for mobile development in IDE (this step was most usefull in my case).
It doesn't solve the problem for 100%, but now i see that random message only few times per week. I will be glad to see real solution.
Just for information - many errors like "file YYY\XXX.pas not found" where with wrong path to the file, it was path somewhere inside of Android SDK. After deleting of all SDKs (fortunately i need only with Win x32/x64 platforms) i never see such errors anymore.
Some time ago i sent it to my colleagues:
Many times i got an sporadic error in Delphi IDE like this:
F2039 Could not create output file '.\dcu\FireDAC.Comp.DataSet.dcu'
When I just tried to compile again, the problem disappeared but compilation may fail on another file. It was especially annoying when I need to rebuild an large project, for example <...>. Finally I discovered that under some conditions Delphi is trying to access files at wrong path:
C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\tools\dcu\FireDAC.Comp.DataSet.dcu
Instead of
C:\M2014\Fellesressurser\felles\FireDAC.Comp.DataSet.dcu
All the time when I get the error it was try to access Android SDK folder instead of my application folder.
If you experienced same problem, you can solve it now, just delete Android SDK from Delphi IDE:
Open “Tools\Options\Environment Options\SDK Manager”
Select installed SDK (list “SDK versions”)
Delete it (button “Delete”)
I'm trying to make an ActiveX control for an application on a Windows CE 6.0 device, but I can't get it to register on the device. When I transfer the .ocx file over to the device and try to register it using regsvrce.exe, it fails with error 7e, which I've learned means a dependency is missing. How can I identify which dependency is missing? Alternatively, have I gone about creating the ActiveX control wrongly?
I have loaded the .ocx in Dependency Walker on my development machine (running Windows 7 64-bit, if that matters) and all of the top-level dependencies it lists are present on the CE device. I can't check further down the tree since Depends then looks for the top-level dependencies on my development machine, half of which are missing since they're CE-specific. Dependency Walker doesn't run on the CE device (unless there's a CE version I've missed?). I tried to copy the DLLs from the CE device to a flash drive so I could load them into DW on my development machine, but the device won't allow me to do so. The OEM tool I have for transferring files unfortunately only transfers to the device. [Edit: I haven't tried writing my own tool to try to pull files from the device to development machine.]
Some details on how I've set up the project, in case I have some wrong assumptions on that end. I have tried with two projects. One has my code in it (the ActiveX Control itself is just a graphical representation of some data, which I had originally set up in a win32 ActiveX control to see how it looks), and one is a clean project - created from template, compiled, downloaded to device; no code added or configuration changed. Both have the same result when trying to register.
Using VS2005, created a project using the "MFC Smart Device ActiveX Control" template, targeting the SDK I received from the OEM.
In the case of the project with my code in it, I copied my drawing code into the project and created the necessary properties for the data input. I can provide more details on my code if it would help, but my issue happens even without the code. I am assuming that since it compiles successfully when targeting the SDK from the OEM that the functions I am using are supposed to be available on the target device.
Build the project in Release configuration (I wondered if the debug libraries were missing on the target device and causing the issue).
Transfer the .ocx file to the target device using an OEM tool.
Start command line on target device, move to directory the .ocx is in, run "regsvrce.exe .ocx". I have also tried transferring all of the files that VS leaves in the build output folder, but the result is the same.
Many thanks in advance for any answers! If you see something obvious point it out - this is my first ActiveX project and my first CE project, so it's very possible I'm missing something basic.
Since you build OCX I assume that you are using MFC. How do you link with MFC? Look in project settings|General, try to select "Use MFC in a Static Library". Same goes for ATL - try selecting "Static Link to ATL" (if you use ATL). This goes also for VCRT - in C/C++|Code Generation, in "Runtime Library" try selecting options without the 'DLL' (i.e. - statically link with VCRT).
Since the default empty OCX does not work for you - this is the only thing I can think of...
Another thing - I assume you have a reason for working with Visaul Studio 2005? Why not a newer version?
Good luck, PazO
I am trying to use an application called CLUT.exe which is an old application for MS-DOS that can be used to reindex NTX files for DBF databases.
(This is not the main topic, but I am just writing this if someone wants to test the app and don't trust at all about the content).
The problem starts when trying to run the command line version through console (cmd.exe) and this error appears:
C:\>CLUT.exe [arg1] [arg2] [arg3]
run-time error R6009
- not enough space for environment
So, according to what I've searched, this could be a possible solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;230205
but it doesn't work and every alternative that I found to solve this over the internet is the same.
Another alternative could be to make right-click in the .exe file, go to Properties then Memory tab and increase the Initial environment memory from Auto to the max value but it doesn't work too.
Well, I am stuck and no "possible" solution is working for me. If someone is interested, knows more about this issue and want to test, you can download the application from here (click "Free Download" green button):
http://www.filebasket.com/free/Development-Clipper-programming-language/clut-exe/13996.html
or directly from my DropBox:
https://dl.dropbox.com/u/15208254/stackoverflow/clut_214.rar
Just to know, I am using Windows 7 and the CLUT.exe application is a Clipper based app (old programming language) that may run under windows console (cmd.exe).
Wikipedia does mention other dos emulators but, oddly, doesn't mention BOCHS.
Reindexing NTX files is not a difficult thing to do, and can be done with tools other than CLUT. For example, many of the utilities listed on this part of Download32 could be used. Otherwise, you could write your own using Harbour Project or xHarbour. Or contact me off list and I'll cook up something in Clipper 5.3.
LATER
If I read the README correctly for CLUT, it's a replacement for the DBU utility that comes with Clipper 5.x. I can supply you with a build of that if you're unsuccessful with other approaches.
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator
I am having some trouble updating UMDF drivers using "devcon" during a
standard code-deploy-debug cycle. The problem is that "devcon update" isn't
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system's driver
cache folder. After a maddening series of experiments I've discovered that
one way to force the thing to use the latest files is by doing the
following:
Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option.
Modify the
resource script file ("DRIVER_NAME.rc") to first define
VER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly define
VER_PRODUCTMAJORVERSION and
VER_PRODUCTMINORVERSION. You'll
note that this system does not allow
us to change the build and the
revision numbers. On Win7 this
seems to be fixed at 7600 and 16385
in "ntverp.h". Is this by design?
So, I first modify "makefile.inc" and set the "-v" option to something like
"1.1.7600.16385" manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.
Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
"C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER" before
running "devcon" then that works too.
Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!
Why can't you just unplug the device and replace the unloaded DLL? You shouldn't need to reinstall the driver, just replace the module. Note that you shouldn't do this during production or anything that has to do with customers, but if you're writing a driver, just slam in the new module with the same version number.
On Win7 this seems to be fixed at 7600 and 16385 in "ntverp.h". Is this by design?
Yep, at least until the next service pack
As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:
http://bit.ly/6PDxKT