My application is able to print its output to a conventional printer using the TPrinter class but i need to be able to set the file location in code when printing to pdf (via Wind2PDF). Win32 has a DOCINFO.lpszOutputproperty that can be set to achieve this - is there a way of setting this in C++ Builder with the TPrinter class ? Looking at the documentation / searching didn't provide any answers.
The DOCINFO struct is used with the Win32 StartDoc() function, which TPrinter::BeginDoc() calls internally. However, BeginDoc() always sets lpszOutput to NULL. So, there is no possibility of specifying an output location with TPrinter. You will have to stop using TPrinter and instead use the Win32 API directly, at least when printing to Wind2PDF.
Related
I have an application what writes commands to some specialized printers directly on LPT1 port. The code looks like this:
AssignFile(t, 'LPT1');
Rewrite(t);
Write(t,#27 + '#'); // initialize
Sleep(50); // avoid buffer fill
Write(t,#27#32 + Chr(0)); // set default font
...
The problem is that when the printer is not connected to the port, the first Write instruction doesn't do anything, it just hangs up and the entire thread is locked.
Is there a way to define a timeout for these instructions, or can you recommend another library that could do this job? It would be great if it had a Write function similar to the one in Delphi, because the amount of code using this approach is very large, and it would be very hard to change all of it.
You can use SetCommTimeouts to configure a timeout for the printer handle. To get the handle from your TextFile variable, type-cast it to TTextRec and read the Handle field:
var
CommTimeouts: TCommTimeouts;
CommTimeouts.WriteTotalTimeoutConstant := DesiredTimeout;
Win32Check(SetCommTimeouts(TTextRec(t).Handle, CommTimeouts));
You may wish to call GetCommTimeouts first to discover the default values for the other fields before you set the ones you need.
Move your printing code to a separate thread. The built-in text-file functions don't have any timeout mechanism, but you can tell the OS to cancel any pending I/O operations whenever you decide that too much time has passed.
I'd start with CancelSynchronousIo, which cancels all I/O on a given thread. It should allow you to keep all your existing Write calls. Be prepared to handle when they fail upon being cancelled.
That function requires Windows Vista or higher, which shouldn't be a problem nowadays, but won't work if you still need support for Windows XP. In that case, you'll need to use CreateFile to open the port for overlapped I/O. Then you can use CancelIo or CancelIoEx. You'll need to replace all your Write calls since the built-in Delphi functions don't support overlapped operations.
My delphi application runs scripts using JvInterpreter (from the Jedi project).
A feature I use is runtime evaluation of expressions.
Script Example:
[...]
ShowMessage(X_SomeName);
[...]
JvInterpreter doesn't know X_SomeName.
When X_SomeName's value is required the scripter calls its OnGetValue-callback.
This points to a function I handle. There I lookup X_SomeName's value and return it.
Then JvInterpreter calls ShowMessage with the value I provided.
Now I consider switching to DelphiWebScript since it has a proper debug-interface and should also be faster than JvInterpreter.
Problem: I didn't find any obvious way to implement what JvInterpreter does with its OnGetValue/OnSetValue functions, though.
X_SomeName should be considered (and actually is, most of the time) a variable which is handled by the host application.
Any Ideas?
Thanks!
You can do that through the language extension mechanism, which has a FindUnknownName method that allows to register symbols on the spot.
It is used in the asm lib module demo, and you can also check the new "AutoExternalValues" test case in ULanguageExtensionTests, which should be closer to what you're after.
I read this paragraph from the Delphi Tools Site
Changes since the last SVN update are:
Added support for FreePascal-like compile-time $INCLUDE “macros”:
%FILE% and %LINE% insert the current filename and line number into the source
%FUNCTION% inserts the current function name, or class.method name into the source
%DATE% and %TIME% allow inserting the compile date/time
Is there a way we can define macros in DWScript (other than these functions) just like people define macors in excel (using VBscript) in a simple way, where the name of the script will be the name of the function that will be used later, without adding {$Include XXX} in the executed script?
N.B.: I konw this can be done by managing the written script to be saved in a certain file called functions for ex. then save the added function with its name to be used (Add), then the user will write Add(1,2) to get the result; but my boss at work wants it to be something that looks like vbscript in excel.
I'm not sure to understand the question, so I'll list various answers to various possible interpretations...
If you want to declare functions that are implicitly supported by the scripting engine without having to "{$include}" or "uses" them, you can declare them via a TdwsUnit component, and attach it to the script component. If you don't have the "coExplicitUses" option set, they'll be available automatically, and you get design-time support in the IDE.
If you want to add internal functions (that are always there), use one of the RegisterInternalFunction overloads, you can check any of the "dwsXxxxFunctions.pas" units for examples. That's potentially more efficient, but also more cumbersome.
If you want to pre-process custom source-level macros in the source code (ala C's macros), you can use the filters functionality (check the HTML or JS filters as example of how a filter can be implemented).
If you want to react dynamically to "unknown" names, so you can declare them on the spot or bind them to something dynamically, you can use TdwsLanguageExtension.FindUnknownName, that's how the RTTI environment works f.i. (see TRTTIEnvironment in dwsRTTIConnector).
If you want to parse completely custom areas of code in a completely custom way, you can use language extensions too, override ReadInstr and check how asmLib & the JSLibModule do it to support "asm".
I'm trying to get rid of some hints(*) the Delphi compiler emits. Browsing through the ToolsAPI I see a IOTAToolsFilter that looks like it might help me accomplish this through it's Notifier, but I'm not sure how to invoke this (through what xxxServices I can access the filter).
Can anyone tell me if I´m on the right track here? Thanks!
(*) In particular, H2365 about overridden methods not matching the case of the parent. Not so nice when you have about 5 million lines of active code with a slightly different code convention than Embarcadero's. We've been working without hints for months now, and we kinda miss 'm. :-)
Even if you could query BorlandIDEServices for IOTAToolsFilter, that interface isn't going to help you do what you're asking. That interface was introduced as part of a mechanism for adding additional build tools (compilers, etc.) to the IDE (before the IDE used MSBuild). It allowed you to write a custom "filter" to handle output from a particular build tool, but it would not let you apply a filter to one of the built-in tools (like the delphi compiler).
The reason the Supports(BorlandIDEServices, IOTAToolsFilter, OTAToolsFilter) call fails in Delphi2010 is that once MSBuild support was added to the IDE, the old way of adding build tools to the IDE was disabled, and the BorlandIDEServices interface no longer supported IOTAToolsFilter.
The declaration of IOTAToolsFilter should probably have been marked deprecated in ToolsAPI.pas (or least it should have been mentioned in the source code comment that it is no longer supported).
As far as your desire to filter a particular hint, I'm not aware of a way to do that via the ToolsAPI. It seems like a reasonable thing that can be added to IOTAMessageServices (the ability to enumerate, filter, and possibly change the messages in the IDE's Message View). I would enter a request in QualityCentral for that.
Also, please vote for QC #35774 (http://qc.embarcadero.com/wc/qcmain.aspx?d=35774), as if that were implemented, you would not need to use the ToolsAPI for this sort of thing.
According to http://docwiki.embarcadero.com/RADStudio/en/Obtaining_Tools_API_Services it should be possible to access it directly using BorlandIDEServices, eg:
var
OTAToolsFilter: IOTAToolsFilter;
begin
if Supports(BorlandIDEServices, IOTAToolsFilter, OTAToolsFilter) then
ShowMessage('supports IOTAToolsFilter')
else
ShowMessage('IOTAToolsFilter NOT supported');
end;
However this doesn't return the desired interface in Delphi 2010 (you'll get the not supported message), so there's either an error in the documentation, or an error in BorlandIDEServices not returning the correct interface.
How can I tell if a module is being called dynamically or statically?
If you are operating on z/OS, you can accomplish this, but it is non-trivial.
First, you must trace up the save area chain and use CSVQUERY to find out which program owns each save area. Every other program will be a Cobol runtime module, like IGZCPAC. Under IMS, CICS, TSO, et al, those modules might be different. That is the easy part.
Once you know who owns all the relevant save areas, you can use the OS LOADER / BINDER / LINKER utilities to discover what artifacts are in the same modules. This is the non-easy part.
The ONLY way is to look at the output of the linkage editor (IEWL) or the load module itself. If the module is being called DYNAMICALLY then it will not exist in the main module, if it is being called STATICALLY then it will be seen in the load module. Calling a working storage variable, containing a program name, does not make a DYNAMIC call. This type of calling is known as IMPLICITE calling as the name of the module is implied by the contents of the working storage variable. Calling a program name literal.
Calling a working storage variable,
containing a program name, does not
make a DYNAMIC call.
Yes it does. Call variablename is always DYNAMIC.
Call 'literal' is dynamic or static according to the DYNAM/NODYNAM compiler option.
Caveat: This applies for IBM mainframe COBOL and I believe it is also part of the standard. It may not apply to other non-standard versions of COBOL.
For Micro Focus COBOL statically linking is controlled via call-convention on the call (bit 3) or via the compiler directive LITLINK.
When linking statically the case of the program-id/entry-point and the call itself is important, so you may want to ensure it is exact and use the CASE directive.
The reverse of LITLINK directive is the NOLITLINK directive or a call-convention without bit 3 set!
On Windows you can see the exported symbols in your .dll by using the "dumpbin /exports" utility and on Unix via the 'nm' utility.
A import .lib for the .dll created via "cbllink" can be created by using the '-K'command line option on cbllink.
Look at the call statement. If the called program is described in a literal then it's a static call. It's called a dynamic call if the called program is determined at runtime:
* Static call
call "THEPROGRAM"
* Dynamic call
call wsProgramName