I am recompiling an application from Visual C++ 6.0 in Visual Studio 2015. It is using Mscomm as serial communication library. Everything gets compiled fine but when I run the program, I get "Attempted an Unsupported Operation" twice. Upon debugging I found out the culprit is the following snippet:
void CFFLSView::DoDataExchange(CDataExchange* pDX)
{
CFormView::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CFFLSView)
DDX_Control(pDX, IDC_MSCOMM1, m_comm);
DDX_Control(pDX, IDC_MSCOMM2, m_comm2);
//}}AFX_DATA_MAP
}
This calls m_comm and m_comm2 to be open COM1 and COM2. I don't have the equipment connected to my computer now, and I will have to test the compiled software at site tomorrow. I suspect that because nothing is connected to COM1 and COM2, the program cannot open port and returns that error but I am not sure that is the case, getting in the site is very difficult and I only have one opportunity to go in and test the software there. I want to make sure that this error is only given because nothing is connected to COM1 and COM2 and not any other problem. I appreciate your comments and thoughts on this. If it helps, the DDX_Control function calls the following function in debug mode:
void CMSComm::SetPortOpen(BOOL bNewValue)
{
static BYTE parms[] =
VTS_BOOL;
InvokeHelper(0x14, DISPATCH_PROPERTYPUT, VT_EMPTY, NULL, parms,
bNewValue);
}
which is supposed to open the port.
Related
I am using C++ Builder XE7 VCL.
Around August 11 2016 2:00pm UTC, I started receiving multiple complaints from my user base about printing problems. Most of these printing modules have proven stable for many years, and there were no updates to my project within the past 24 hours. I was able to reproduce similar problems on my development/test environment.
Without going into many details of my project, let me present a very simple printing program that is failing:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
Prntr->BeginDoc();
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
if (Prntr->Printing) {
Prntr->EndDoc();
}
}
On the first attempt to print, everything works perfectly as expected. If I click the button a second time, TPrinter produces a small PDF, but the PDF file is actually corrupted and appears to have a file handle stuck to it.
If I click the button a third time, I get no printing and the following error message appears:
Printer is not currently printing.
My own test was done using a PDF printer driver, but the complaints I am receiving from users include a variety of local printers, network printers, PDF printers, etc.
In my actual project, I have try/catch exception handling, so the actual results are slightly different, but substantially similar to this result. The results show the hallmarks of instability and/or memory leaks without much in terms of error messages.
I suspect there may have been some Microsoft Windows updates that are tangling with Embarcadero DLLs, but I have not been able to verify this so far.
Is anyone else having similar problems?
The reason using a TPrintDialog or TPrinterSetupDialog "works" to fix the error is because they force the singleton TPrinter object (returned by the Vcl.Printers.Printer() function) to release its current handle to a printer if it has one, thus causing TPrinter.BeginDoc() to create a new handle. TPrinter releases its printer handle when:
it is being destroyed.
its NumCopies, Orientation, or PrinterIndex property is set.
its SetPrinter() method is called (internally by the PrinterIndex property setter and SetToDefaultPrinter() method, and by TPrintDialog and TPrinterSetupDialog).
Without doing that, calling TPrinter.BeginDoc() multiple times will just keep re-using the same printer handle. And apparently something about the recent Microsoft security update has now affected that handle reuse.
So, in short, (without uninstalling the Microsoft update) in between calls to BeginDoc() you need to do something that causes TPrinter to release and recreate its printer handle, and then the problem should go away. At least until Embarcadero can release a patch to TPrinter to address this issue. Maybe they could update TPrinter.EndDoc() or TPrinter.Refresh() to release the current printer handle (they currently do not).
Therefore, the following workaround resolves the printing issue without requiring any changes to the user interface:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
Prntr->Copies = 1; // Here is the workaround
Prntr->BeginDoc();
if (Prntr->Printing) {
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
}
There are no Embarcadero DLLs involved in printing. TPrinter simply calls Win32 API GDI-based print functions directly.
The "Printer is not currently printing" error occurs when one of the following operations is performed on a TPrinter when its Printing property is false:
TPrinter::NewPage()
TPrinter::EndDoc()
TPrinter::Abort()
a TPrinter::Canvas subproperty is being changed.
the TPrinter::Canvas is being drawn on.
You are performing half of these operations in the test code you have shown, but you did not specify which line of code is actually throwing the error.
The Printing property simply returns the current value of the TPrinter::FPrinting data member, which is set to false only when:
the TPrinter object is initially created (the Printer() function returns a singleton object that is reused for the lifetime of the executable).
the Win32 API StartDoc() function fails inside of TPrinter::BeginDoc() (FPrinting is set to true before StartDoc() is called).
TPrinter::EndDoc() is called when Printing is true.
So, given the test code you have shown, there are two possibilities:
StartDoc() fails and you are not checking for that condition. BeginDoc() will not throw an error (VCL bug?!?), it will simply exit normally but Printing will be false. Add a check for that:
Prntr->BeginDoc();
if (Prntr->Printing) { // <-- here
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
the Printing property is getting set to false prematurely while you are in the process of printing something. The only ways that could happen in the code shown are if:
random memory is being corrupted, and TPrinter happens to be the victim.
multiple threads are manipulating the same TPrinter object at the same time. TPrinter is not thread-safe.
Since you can reproduce the problem in your development system, I suggest you enable Debug DCUs in the project options, then run your app in the debugger, and put a data breakpoint on the TPrinter::FPrinting data member. The breakpoint will be hit when FPrinting changes value, and you will be able to look at the call stack to see exactly which code is making that change.
Based on this information, I am going to go out on a limb and guess that the cause of your error is StartDoc() failing. Unfortunately, StartDoc() is not documented as returning why it fails. You certainly cannot use GetLastError() for that (most GDI errors are not reported by GetLastError()). You might be able to use the Win32 API Escape() or ExtEscape() function to retrieve an error code from the print driver itself (use TPrinter::Canvas::Handle as the HDC to query). But if that does not work, you won't be able to determine the reason of the failure, unless Windows is reporting an error message in its Event Log.
If StartDoc() really is failing, it is because of an Win32 API failure, not a VCL failure. Most likely the printer driver itself is failing internally (especially if a PDF print driver is leaving an open file handle to its PDF file), or Windows is failing to communicate with the driver correctly. Either way, it is outside of the VCL. This is consistent with the fact that the error started happening without you making any changes to your app. A Windows Update likely caused a breaking change in the print driver.
Try removing the following Windows update:
Security Update for Microsoft Windows (KB3177725)
MS16-098: Description of the security update for Windows kernel-mode drivers: August 9, 2016
This appears to resolve the issue for several test cases so far.
It started happening here today too. On my Windows 10 setup this would happen after calling TForm's Print() 3 times. I tried both the Microsoft Print to PDF and the Microsoft XPS Document Writer and both gave the same error.
I did some quick debugging and found that it's the call to StartDoc() that returns a value <= 0.
A temp fix until I can figure out what is really causing this is to re-create the Printer object in Printers by calling
Vcl.Printers.SetPrinter(TPrinter.Create).Free;
after calling anything that is using the Printer object. Might not be advisable to do that, but it solved my issue for now.
Looks like something is not released properly when calling EndDoc()
It seems that this is really a Microsoft problem and they should fix this buggy update. You can find more info at this on the company site.
Using a Printer Setup Dialog is only a workaround, not real solution, for this Microsoft bug. After confirmation, the printer setup dialog always creates a new handle for the printer. The next one or two print jobs will then succeed.
The patch should come from Microsoft, not from Embracadero. Thousands of programs are affected and it would be a massive waste of time and money to implement a workaround in all of them, if there is a bug in MS update.
I started experiencing the same weird behavior at more or less the same time, when running 32 bit Delphi applications built in XE7 on a Windows 10 64 bit system.
After uninstalling the latest security upgrade for Windows 10 (KB3176493), printing from these applications works normally again.
A rather surprising side effect of uninstalling this update seems to be that the file associations - which are the default programs for handling specific file types - are being reverted to Microsoft Windows default values...
The following variation of the code in the question will resolve the problem, but requires a TPrinterSetupDialog component added to the form:
void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
// Test Print:
TPrinter *Prntr = Printer();
Prntr->Title = "Test_";
PrinterSetupDialog1->Execute();
Prntr->BeginDoc();
if (Prntr->Printing) {
Prntr->Canvas->Font->Size = 10;
Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
Prntr->EndDoc();
}
}
For program usage, the user will be presented with the printer setup dialog before proceeding to printing.
As to "why", my best guess at this point is that TPrinter used alone does not have all necessary permissions to access all necessary resources from Windows after the Security Update for Microsoft Windows (KB3177725) was implemented on Aug 10, 2016. Somehow a call to TPrinterSetupDialog (or TPrintDialog) before calling BeginDoc() sets up the necessary conditions for TPrinter to perform successfully.
I'm struggling with exception handling inside my Datasnap REST Service (Delphi XE3 but also tried with Delphi 10 Seattle). I have written half a dozen Windows Service over the years and I always include a TApplicationEvents component so that I can log any Application Exceptions to the Windows Event Log.
However, this behaviour is not happening with a Datasnap Service. The TApplicationEvents.OnException event never gets fired, so I assume something else is eating the exception and handling it before it gets here.
The exception is displayed in the web service method's result, which is fine because it means I can at least display something on the client side, but I'd also like to catch it before then so that I might be able to handle different exceptions server-side.
The only consistent way I have managed so far is to wrap each individual method in a try..except block, and handle the exception in each method, before re-raising the exception. However, with a Web Service of 20 methods and growing, this isn't really going to scale up.
I have also tried implementing the OnError, OnTrace and other events of the some of the Datasnap components (TDSServer, TDSHTTPService, TDSTCPServerTransport, etc.) but these never seem to get fired either.
Has anyone come across anything like this, please?
Tl;Dr: it's not implemented in a usable fashion (in 10.1 Berlin).
I came across the same problem and after reading through a lot of source, I found no practical solution.
So an exemplary (my) StackTrace would look like this:
MyClass::MyServerMethod()
/* skipping some funny unimportant RTTI/TValue handling here */
System::Rtti::TRttiMethod::Invoke
Dsreflect::TDSMethod::Invoke(TObject, TDSMethodValues)
TDSServerConnectionHandler::DbxExecute(const TDBXExecuteMessage)
TDSServerCommand::DerivedExecuteUpdate
TExecuteCallback
TDSService::Execute(const string, const TRequestCommandHandler, TExecuteCallback)
TDSService::ProcessRequest(const string, const TRequestCommandHandler, TExecuteCallback)
TDSRESTService::ProcessREST(const string, const string, const TArray<Byte>, const TRequestCommandHandler)
TDSRESTService::ProcessGETRequest(const string, TStrings, TArray<Byte>, TRequestCommandHandler)
TDSRESTServer::DoDSRESTCommand(TDSHTTPRequest, TDSHTTPResponse, string)
TDSRESTServer::DoCommand(TDSHTTPContext, TDSHTTPRequest, TDSHTTPResponse)
Dshttpwebbroker::TDSRESTWebDispatcher::DispatchRequest(TObject, Web::Httpapp::TWebRequest, Web::Httpapp::TWebResponse)
Note: This depends entirely on your usage of DataSnap. In the above case requests are passed into the DataSnap API through TDSRESTWebDispatcher (comming from TIdCustomHTTPServer).
Every Exception raised in a ServerMethod will end up in TDSService::ProcessRequest.
In this procedure every Exception is caught and ONLY its Message is added to a TRequestCommandHandler->CommandList.
Further down the Message is written as JSON/DBX command to the output.
So we can never handle the Exception Object and access the StackTrace or other information. So this alone is unacceptable and has to change
The good news is, that this procedure is virtual and can be overwritten. The bad news is, that in the example above you would have to extend TDSRESTService with your own ProcessRequest procedure (including your errorhandler), TDSRESTServer with own DoDSRESTCommand (in there the TDSRESTService is created in a monstrously large procedure) and TDSRESTWebDispatcher (depending on your usage).
My personal recommendation is to don't use DataSnap.
Note: At the point of writing this, I haven't found any invoke of the OnError event.
When Distributed Transaction Coordinator (DTC) is not running, our MVC C# site throws strange misleading errors, confusing developers and testers. We want to do a code check that the service is running and flag the issue on something like Global.asax. Any way to do this?
The below code starts the MSDTC service on the local machine if it's currently "Stopped"
You need to reference the System.ServiceProcess assembly
using(var msDtcSvc = new System.ServiceProcess.ServiceController("MSDTC"))
{
if(msDtcSvc.Status == System.ServiceProcess.ServiceControllerStatus.Stopped)
{
msDtcSvc.Start();
}
}
I am developing this Delhi 2009 app with SQLite database version 3.7.9, accessed by the Zeos components. Started off OK - I can create a DB if none exists, create tables and insert records - the 'normal stuff'. There is a little table that contains serial params for a connection to some old equipments and the serial comms handler needs to be informed of connection parameter changes, but the Zeos components do not support events on SQLite.
I looked at the SQLite API and there is a 'Data change notification callback', so I set about making this happen. The setup prototype is:
void *sqlite3_update_hook(
sqlite3*,
void(*)(void *,int ,char const *,char const *,sqlite3_int64),
void*
);
So, in Delphi, I imported the DLL call:
function sqlite3_update_hook(pDB:pointer;pCallback:pointer;aux:pointer): pointer; stdcall;
..
function sqlite3_update_hook; external 'sqlite3.dll' name 'sqlite3_update_hook';
..and declared an empty callback for testing:
function DBcallback(aux:pointer;CBtype:integer;CBdatabaseName:PChar;CBtableName:PChar;CBrowID:Int64):pointer; stdcall;
begin
end;
..and called the setup:
sqlite3_update_hook(SQLiteHandle,#DBcallback,dmOilmon);
SQLiteHandle is the sqlite3* pointer for the database as retrieved from the driver after connection. dmOilmon is the DataModule instance so that, when working correctly, I can call some method from the callback, (yes, I know callback is in an unknown thread - I can deal with that OK, I'll just be signaling semaphores).
Good news: when I ran the app, the DBcallback was called, aparrently successfully, upon the first insert. Bad news: some little time later, the app blew up with 'Too many exceptions', and usually a CPU window full of '??', (the occasional alternative was system death and a reboot - Vista Ultimate 64). Breaking in the callback, aux, CBtype and CBrowID were all as expected but the debugger tooltip showed the CBdatabaseName / CBtableName PChars to be pointing at a string of Chinese characters..
I tried to trace where the callback is called from - the call chain passes through in the Zeos driver code, for some reason. Breaking there and stepping through, I checked the stack pointer and it's the same before and after the callback.
So, I set up the 'empty' callback, the callback gets called at the expected point but with a coupe of dodgy-looking parameters, the callback returns to whence it came with the SP correct. I seem to have done everything right, but... :((
Has anyone seen this, (or fixed it even:)?
Can you suggest a mechanism whereby an aparrently successful callback can pesuade an app to later generate recursive exceptions?
Does anyone have any suggestions for further debugging?
Rgds,
Martin
You have the problems with correct translation of SQLite header to Delphi and with linking:
Not stdcall, but must be cdecl.
Your function DBcallback must be a procedure. Because void(*)(...) is a pointer to C function returning void.
Not PChar, but must be PAnsiChar. For non-Unicode Delphi's it may be not important, for Unicode Delphi's, it is only a correct translation.
You are using compile-time dynamic linking (external 'sqlite3.dll' ...) to sqlite3.dll. But ZeosLib uses run-time dynamic linking (LoadLibrary & GetProcAddress). That may lead to "DLL hell" issue, when your EXE loads one sqlite3.dll, and ZeosLib plans to load another sqlite3.dll.
This is driving me nuts...
Two assemblies/projects in play:
An Infrastructure project, which has an interface in it:
IDtoMapping<in TDto, out TDomain>
And an app project, referencing Infx, with an implementation:
PatientMapping : IPatientMapping
...and a marker interface, just to be clear:
public interface IPatientMapping : IDtoMapping<PatientDTO, Patient> {}
When the app boots, this gets run:
_container.RegisterType<IPatientMapping, PatientMapping> ( new ContainerControlledLifetimeManager () );
This happens in the app project, through a system-wide bootstrapping process.
(Immediately after this line runs, (through a watch), I can successfully resolve it.)
Finally, we try to resolve it (in a WCF service, in the app projec)
public PatientService (
IPatientRepository patientRepository,
ISessionSource session,
IPatientMapping patientDtoToDomainMapper )
{
.. and it fails. With the ResolutionFailedException "Cannot instantiate an interface, etc.." I've put break points at the .Resolve call, the registration, etc.. everything is getting hit as expected. But when the app tries to Resolve/BuildUp the WCF Service, Unity can't resolve the IPatientMapping parameter... it's like it forgot.
I'm at a loss.. I upgraded to Unity 2.0, added that intermediate marker interface, removed the generic interface and just used the vanilla one.. all to no avail.
Other dependencies in the system resolve just fine, including the other parameters on that same WCF constructor.
The only thing my gut is telling me is could it have something to do with the assemblies? That the .Resolve call is happening in the Infx project, but the implementation actually lives in the app-project? At runtime, all assemblies are loaded, so it shouldn't really matter, right?
Thanks for any ideas!