I was looking for some Windows API that will give me notification for any change in the Local Area Connection Properties.I tried Searching for the Entry in the Registry which it modifies after we check or uncheck the driver name but could find it.
I have also attached an image if any one has any confusion in understanding my question.
Any guidance would be appreciated.
What you need is the Windows API for Network Awareness. It would be great if Delphi example implementations were readily available but they are not. The API's are all COM interfaces and you will have to find out how to use these within Delphi yourself. That is another question. However, for the INetworkConnection, this may get you started.
Related
As per topic. I have very old machine that i cannot replace (some old railway machine). That machine still uses 3.5zip drive. I need to fit the USB instead. Therefore, as i`m completely not familiar with this system, can someone direct me please on where to start to reconfigure this ( if manageable of course) for use with USB? I guess there would a need for drivers etc so the USB is discoverable.
Thanks a lot in advance.
You'll need to download io-usb (the USB server) and Fsys.usb (the USB bulk storage driver).
Start here:
http://foundry27.com/sf/wiki/do/viewPage/projects.qnx4/wiki/InstallationNotesForUSBStack?selectedTab=versions&version=4
Continue here:
https://openqnx.com/phpbbforum/viewtopic.php?t=11230
Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.
I'd like to get information about a third party application's controls such as a list of its properties and their values: something like RTTI information but for a third-party Delphi application.
I see that this is possible. For example TestComplete has the ObjectSpy window which can give many useful information about the control, including RTTI information. How can this be done ?
Edit: To explain why I'm investigating this issue... I'm a registered user of TestComplete/TestExecute and I do like... most of it. I can get over the minor things but the one major problem for me is their license verification system which requires me to have a physical computer (not a virtual machine) always on just for the sake of running a license server so that TestExecute can run at night. As I have basic testing needs (compare screenshots and check basic Delphi component's properties) I wondered how hard it would be to make my own private very simple "TestExecute-like" application.
To go further, I suggest you these relevant resources found here on SO
Writing a very basic debugger (The accepted answer along with its comment thread are all valuable).
Is it possible to access memory from an application to another ? How? (Excerpt from the accepted answer: It is possible. Just use the Windows API functions WriteProcessMemory/ReadProcessMemory. Pass in the handle of the process and the pointer to the data).
Search the memory of another process (The excellent accepted answer also forwards to another valuable resource delphi-code-coverage by Christer Fahlgren and Nick Ring).
StackWalk of other process in delphi? (Check Barry Kelly's answer !!!, the same for the one from the AsmProfiler author !!!).
I strongly suggest you to port to Delphi this c++ project entitled Get Process Info with NtQueryInformationProcess: A hands on experience on using ReadProcessMemory to access the CommandLine used to launch another process.
Last Edit:
NtQuerySystemInformation Delphi Example.
RRUZ's answer to Delphi - get what files are opened by an application as suggested by LU RD.
When we want to take another application which is compiled with debug information and get stuff out of it at runtime, what we are dealing with is the problem of "how to write my own custom debugger/profiler/automated-test kernel".
TestComplete and other AutomatedQA programs contain a Debugger and Profiler Kernel which can start up, run and remotely control apps, and parse their Debug information in several formats, including the TurboDebugger TD32 information attached to these executables. Their profiling kernel also can see each object as it is created, and can iterate the RTTI-like debug information to determine that an object that was created is of a particular class type, and then see what properties exist in that object.
Now, TestComplete adds on top of the AQTime-level of stuff, the ability to introspect Window handles, and intuit from Window Handles, the Delphi class Names that are behind it. However, it's much easier for you (or me) to write a program which can tell you that the mouse is over a window handle that belongs to a TPanel, than to know which version of Delphi created that particular executable, what version of TPanel that is, then, and what properties it would contain, and to read those values back from a running program, which requires that you implement your own "debugger engine". I am not aware of any open source applications that you could even use to get a start writing your own debugger, and you certainly can't use the ones that are inside AQTime/TestComplete, or the one inside Delphi itself, in your own apps.
I could not write you a sample program to do this, but even if I could, it would require a lot of third-party library support. To see the window classes for a window handle which your mouse is over, look for how to implement something like the MS Spy++ utility.
An easy case is if your mouse is mousing over a window inside your own application. For that, see this about.com link, which simply uses RTTI.
I am trying to build a very simple driver. Its sole purpose will be to register "PsSetCreateProcessNotifyRoutine" and on callbacks recieved from kernel, notify my Win32 application about which proccesses are started and stoped.
I only know how to build such a simple driver with "DriverEntry" and "DriverUnload" and compile it with DDK. But I don't know how to actually implement communication. I know it can be done with IOCTL. But beyond that I am in the dark. I cannot find simple example of how to do that in Delphi. I only know it can be done.
So what I am looking for is some simple and understandable tutorial on how to do it or event better an example delphi program with acompaniying driver code. Maybe there are even other ways of communication.
Any help would be appriciated.
Doesn't matter if in Delphi or not. You have to use the function DeviceIoControl. Read the article in MSDN about it.
In short, you'll have to choose some IOCTL codes from the available set. Then you call DeviceIoControl with one of these codes and pass some data, and in driver you handle that request and return something else.
You can also handle standard IOCTLS, such as the ones generated by calling ReadFile or WriteFile in user-mode.
Don't look for a "tutorial how to do that in Delphi", just look for any tutorial. They're all the same, no matter the language, it's pure Win32/Native api stuff. Here's one for example, just googled it out.
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.