I want to monitor the copy file function using Delphi.
I can do it in windows explorer with shell notifier.
My problem is when copying file with the command prompt.
How can I monitor the progress of a copy file operation that has been initiated at the command prompt, using Delphi?
I personally used these two:
When using .NET, use the System.IO.FileSystemWatcher class.
When using Win32, use a combination of FindFirstChangeNotification, FindNextChangeNotification and FindCloseChangeNotification.
Ah - just found out the Win32 portion of your question is also answered here, and that answer has a code example.
There is also another Win32 way of doing this: using ReadDirectoryChangesW, but I don't have personally used it.
Good luck!
--jeroen
Related
this is problem.
I developed a shell extension of Shell Context Menus.
(use SharpShell, enter link description here)
I can register it by using regasm.exe with "/codebase" attribute.
And without this attribute the shell extension doesn't work.
But this attribute let me can't update the .dll file without reboot explorer.
Even worse, can't delete .dll file after that unregistered and reboot PC (in windows 8).
So, did that have any way to solve this problem?
By the way, if anyone can tell me what is "/codebase" actually doing?
(I saw MSDN already, but totally can't understand.)
The only solution is to enumerate the handles created by explorer.exe and filter them by the target file, which is your own locked dll file. Then you can remove the handle.
It would require P/invoke if you will use C#, or handle.exe by Sysinternals if you will use any scripting language during installation. However, removing handles in the background of the application that has the handle is an unsupported way and may result with undefined consequences.
In an Inno install script, I am setting an environment variable by adding an entry to:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
I want my users to be able to run the newly installed app without having to reboot (which would normally be necessary for the above change to be seen in the environment.)
I plan to have the installer use a dll to call SendMessageTimeOut, as discussed here: Set environment variables from Delphi (Win32).
Delphi XE2 reports this API is deprecated.
And the above StackOverflow thread suggests using SendNotifyMessage to avoid long waits. I don't know how to construct that call.
Can anyone show me the syntax? Is it deprecated too?
Any suggestions on a better approach?
Tom
You might want to take a look at the ChangesEnvironment directive. From the docs:
When set to yes, at the end of the installation Setup will notify
other running applications (notably Windows Explorer) that they should
reload their environment variables from the registry.
Neither function is deprecated. Delphi says SendMessageTimeout is deprecated because that declaration is deprecated. The API function itself is fine. Since you'd be calling it from something that isn't Delphi, whatever Delphi says about its declaration is irrelevant to you.
Since you don't actually care about the return value of the message, SendNotifyMessage is the superior choice. It won't wait at all for a response, whereas SendMessageTimeout will wait a little while to get a response, which you're just going to ignore anyway.
But as Mirtheil's answer points out, the installer environment you're using already provides a way of notifying other programs that the environment changed, so you should use that instead of trying to do it manually.
My company has a program that uses Lua embedded in its runtime, loading up .lua files from disk and executing functions defined in them repeatedly.
Is there a way to attach to the running process and set breakpoints in my .lua files? (I'd accept either gdb-style command-line debugging as part of the Lua distribution, or perhaps a third-party IDE that provides Visual-Studio-like GUI breakpoints.)
Or is what I'm asking for entirely nonsensical and impossible given the nature of the runtime loading up random files from disk?
Edit: Looks like it's not nonsensical, given that Lua's own debug.getinfo() function can determine the source file for a given function, and debug.sethook() allows a callback for each new line of code entered. So, it's reasonable to load source code from disk and be able to tell when the interpreter is executing a particular line of code from that file. The question remains: how do I latch onto an existing process that has a Lua interpreter and inject my own trace function (which can then watch for file/line number pairs and pause execution)?
If you can modify the .lua files, you can insert the following call just before anything you need to debug:
require 'remdebug.engine'.start()
It starts the RemDebug Lua debugger engine and tries to connect to a controller. If it cannot connect, it will just continue running as normal. I did some fixes to the debugger engine, such as dealing with temporary variables, and my student is working on a debugger GUI (due next year).
In the meantime, you can try if Lua Development Tools works for you. It features a debugger similar to RemDebug, which should be possible to set up as follows:
require("debugger")(host, port, idekey)
Alternatively, you can use SciTE-debug, which is an extension to the SciTE editor, and can serve as a controller to RemDebug. Just make sure you insert the call to remdebug.engine.start somewhere in your Lua code and insert this into the SciTE output window:
:debug.target=remote.lua
When you start your program, SciTE should show the source and current line.
I've been using Decoda editor for that. It allows you to attach to a running C++ application, after that it detects that you're running a Lua Interpreter within your C++ code and show your Lua source code, where you can add beakpoints and inspect variables as usual.
This is an alternative I use after much searching. If you have an external executable that loads lua, I got this working in a few minutes. The op is very responsive, it has an interactive debugger which loads your code you can place debug points interactively. It doesn't have an editor, but I use scite or crimson editor and start the executable, one line in your main lua module enables the debugger.
http://www.cushy-code.com/grld/ - this link seems dead now
I've moved to eclipse.org/ldt it has an ide and integrated debugger, recommended
hth
The Lua plugin for IntelliJ has a working debugger with no special setup required other than pointing to your Lua interpreter.
Here's a screencast of it:
http://www.screencast.com/t/CBWIkoZPg
Similar to what Michal Kottman described, I have implemented a debugger based on RemDebug, but with additional fixes and features (on github: https://github.com/pkulchenko/MobDebug).
You can update your .lua file with require("mobdebug").start("localhost", 8171) at the point where you want the debugging to start. You can then use the command line debugger to execute commands, set breakpoints, evaluate/execute expressions and so on.
As an alternative, you can use ZeroBrane Studio IDE, which integrates with the debugger and gives you a front-end to load your code and execute same debugger commands in a nice GUI. If you want to see the IDE in action, I have a simple demo here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
You should probably use Decoda.
Go to Debug -> Processes -> Attach to attach your process. This should work fine.
Well the easiest way is this, thanks to the genius author
https://github.com/slembcke/debugger.lua
you don't need to setup a remote debug server ,just require one file,and simplely call dbg() and it will pause,just like gdb
an tutorial is also shipped with it, check it out.
I'm not a developper. We want ( me and our team)to write a tool in C++ that can print a PDF ( Send a PDF to printer). We tried to use external tool, like a command line pdfprint.exe, using CreateProcessW and cmd /c, but we have a problem. With Windows XP we don't have problem with our tool, with Windows Vista we have problem and we cannot using the tool like pdfprint.exe.
There are differences between Windows XP and Vista to launch external tools within another program with CreateProcessW and "cmd /c"?
Thanks
Oronzo
There are many approaches to run external application from your C++ programm. I will count them below.
Win32API CreateProcess function. Cédric Julien gave example of use.
exec* C/C++ function family. They are defined in POSIX standard. So they are the same on Linux. But because they are deprecated in new version of MSVC, try to use analogical _exec* function.
WiNT Native API Call - NtCreateProcess. It is called in CreateProcess also :-) And this function represents deeper level of API. With use of Native API calls you can write small and simple applications, because you will make lesser number of dependencies of your program with external libraries. But there are issues: native API is binded to OS version, so there aren't any garanties that Native API will be the same in next OS versions.
You may try each. Please, note that it is good idea to point in each call to these functions full path to executable file. Also you must have read/execute rights (permissions) on pdfprint.exe. If you don't have such only way to execute external tool is to run your C++ program with administrative rights. You can run it such way if you right click on exe-file of your program and select "Run As Administrator" menu element.
As described here, you should use something like this :
LPTSTR szCmdline = _tcsdup(TEXT("C:\\Program Files\\....\\pdfprint.exe -args-you-need"));
CreateProcess(NULL, szCmdline, /* ... */);
i have an application which call another console application and pass to it some parameters (console app is a video/audio coverter app) ... is there a way to programmatically "spy" or catch the passed paramters other than hooking/monitoring shellexecute/CreateThread etc ?
Create an executable yourself that just calls the original and passes all parameters on to it. Then move the original somewhere else and replace it with your exe. Your program can then log all calls to it, including all parameters.
Yes, there is - as you write Process Explorer is able to do it, and you could employ the same technique. But AFAIK there's no Delphi translation of the winternl.h file from the Platform SDK, so it is even more tedious and difficult. Also this is extremely version-specific, and there are chances it will break with the next Windows version. It's also not quite clear whether this works for 64 bit processes (from a 32 bit process).
If you really want to do it you will find the necessary information in this blog posting by Matt Pietrek, and in the CodeProject article "Read Environment Strings of Remote process".
If you do not plan to use it for closed source commercial programs then a look into the (GPL licensed) annotated version of the winternl.h file from the ReactOS project would probably also help.
It's a Win32 FAQ since 1992 : just read the PEB.
See on Win32 experts group.