So I've got an application in Embarcadero's RAD Studio that I'm working on. It is a VCL application with a separate thread that is handling I/O off board the PC. Inside a function in the thread I have code that looks like this....
if(run)
{
/* run I/O code here */
}else
{
/* stop I/O here */
}
run is a global boolean variable in the thread's .h file. It's state is changed by a button on the form. When debugging the app, a breakpoint on the first line of the code shows the value of "run" toggling true and false with the button press however the code ALWAYS executes the first part of the if statement and run the I/O code?? What gives? Am I missing something?
Thanks!
Related
I have code that calls RenameFile().
The Result passed back is sometimes False; this appears to happen when the (.pdf) file is in use.
I have seen what appears to be a 'standard' message loop in everyday programs where, if an operation can not be executed against a file that is in use, the message prompts the user to close the file and try again (or Cancel).
Is there a function in Delphi that does this, or does anyone have a coding suggestion that mimics this behavior?
I am working in Delphi-Tokyo.
Thanks!
I'm new to MQL language, so please correct me if I described something wrong.
I made an script by the script editor to place orders automatically. The program should be never stopped unless by manually termination. My code looks like that:
void onStart()
{
While(true)
{
Sleep(10000);
MakeOrder(....);//of course actual code is much more complicated
}
}
The only preset functions I use are trade functions, math functions and time functions.
The code works well for most of the times that can continue running at least for 48 hours, but sometimes it might unexpectedly stopped reporting deinit reason 4(which is the same exit code if I click stop button when debugging) within one hour after starting. It looks that MQL doesn't have try...catch module, and getting error in some coding lines won't stop it. I wonder what might have happened behind the termination? Or how can I ignore it, so at least the program can automatically restart?
You should check the OnTimer and OnTick functions.
And recommended to use IsStopped() in the While loop.
void onStart()
{
while(!IsStopped())
{
Sleep(10000);
MakeOrder(....);//of course actual code is much more complicated
}
}
Uninitialization Reason 4 is : chart has been closed. In MT4, you always need to run a script on a chart (window), so of course if this chart is close for any reason, your script will terminate. There is nothing you can do to prevent that.
As suggested, adding IsStopped() will terminate your loop (and script), so what you can do is to add some code after your loop to notify you the script is being terminated.
For example :
void OnStart()
{
//---
while(!IsStopped())
{
Sleep(10000);
//MakeOrder(....);//of course actual code is much more complicated
}
//---
if(UninitializeReason()==REASON_CHARTCLOSE)
{
string msg="Chart is closed and the script is terminated.";
Alert(msg);
SendNotification(msg);
}
}
Update: I've updated the text below to reflect results of my further investigations.
I want to debug my Windows CE 6 service from Visual C++ 2008. But breakpoints in several service API functions don't get hit, while should be. And that's not all. Seems like setting a breakpoint sometimes changes the code flow.
I have breakpoints set on all the service's exported functions (xxx_Init, xxx_Open, xxx_IOControl, etc.). I deploy the service DLL debug binary to a device and then I attach the debugger to the servicesd.exe process on the device.
After I run
services load MYSVC
on the device console, the module gets loaded, all the breakpoints become enabled and then the breakpoint in the xxx_Init function gets hit. I then execute and exit the function by pressing F5 in VC++. So far, so good.
But then, I run the
services start xxx:
command. Under the hood it calls the CreateFile API which results in a call to my xxx_Open function. If the CreateFile succeeds, then the DeviceIoControl API is called, which in turn calls my xxx_IOControl.
My implementation of xxx_Open just logs and returns a non-zero value, allowing the upper CreateFile API call to succeed:
DWORD APIENTRY xxx_Open(DWORD data, DWORD access, DWORD shareMode)
{
APP_LOG_INFO() << L"The service is being opened";
return 1; // Breakpoint here
}
If there is a breakpoint set on the "return 1" line, the breakpoint does not get hit, but I've got the
xxx: is not a valid service
response on the console, as if the function returned 0. If I remove the breakpoint, then everything goes fine.
The same goes if I set a breakpoint on the code in xxx_IOControl function:
DWORD xxx_IOControl(DWORD code, /* ... */)
{
DWORD error = ERROR_SUCCESS; // (1)
switch (code) // (2)
{
...
default: // (3)
...
}
Having a breakpoint on the line (1) leaves the error variable unitialized. Having a breakpoint on the line (2) makes the code to fall to the default branch on line (3), even if there exists a case branch for the code provided. In any of these cases the breakpoints are not hit.
At the same time, if I LoadLibrary my DLL (from a test executable), GetProcAddress of the xxx_Open and xxx_IOControl and call them, the debugger works as intended, all the breakpoints get hit and the code flow seem to be correct.
What am I missing? Why the debugger interfere with the services in such a weird way? Is there a way to reliably debug the service functions (I need IOControl mostly)?
Say have a few blocks of code in my project with this pattern:
dispatch_semaphore_wait(mySemaphore);
// Arbitrary code here that I could get stuck on and not signal
dispatch_semaphore_signal(mySemaphore);
And let's say I pause in my debugger to find that I'm stuck on:
dispatch_semaphore_wait(mySemaphore);
How can I easily see where the semaphore was last consumed? As in, where can I see dispatch_semaphore_wait(mySemaphore); was called and got through to the next line of code? The trivial way would be to use NSLog's, but is there a fancier/faster way to do this in the debugger with Xcode 4?
You can print debugDescription of the semaphore object in the debugger (e.g. via po), which will give you the current and original value (i.e. value at creation) of the semaphore.
As long as current value < 0, dispatch_semaphore_wait will wait for somebody else to dispatch_semaphore_signal to increment the value.
There is currently no automatic built-in way to trace calls to dispatch_semaphore_signal/dispatch_semaphore_wait over time, but that is a useful feature request to file at bugreport.apple.com
One way to trace this yourself would be by creating symbolic breakpoints on those functions in Xcode, adding a 'Debugger Command' breakpoint action that executes bt and setting the flag to "Automatically continue after evaluating" the breakpoint.
Another option would be to use DTrace pid probes to trace those functions with an action that calls ustack().
I have a problem also described here: http://www.delphigroups.info/3/9/106748.html
I have tried almost all forms of placing Application->Terminate() func everywhere in the code, following and not 'return 0', 'ExitProcess(0)', 'ExitThread(0)', exit(0). No working variant closes the app. Instead the code after Application->Terminate() statement is running.
I have two or more threads in the app. I tried calling terminate func in created after execution threads and in main thread.
Also this is not related (as far as I can imagine) with CodeGuard / madExcept (I have turned it off and on, no effect). CodeGuard turning also did not do success.
The only working code variant is to place Application->Terminate() call to any of any form button's OnClick handler. But this does not fit in my needs. I need to terminate in any place.
What I should do to terminate all the threads in C++ Builder 2010 application and then terminate the process?
Application->Terminate() does not close application immediately, it only signals you want to close the application.
Terminate calls the Windows API
PostQuitMessage function to perform an
orderly shutdown of the application.
Terminate is not immediate.
In your functions call Application->ProcessMessages() then check if the Application->Terminated property is true.
For applications using
calculation-intensive loops, call
ProcessMessages periodically, and
also check Terminated to determine
whether to abort the calculation and
allow the application to terminate
For example:
void Calc()
{
for (int x = 0; x < 1000000; ++x)
{
// perform complex calculation
// check if need to exit
Application->ProcessMessages();
if (Application->Terminated)
{
break;
} // end if
} // end for
// clean up
}