I tried with many versions of MAPISend, but I everytime got error in one place.
The MAPILogon returns with errorcode 1.
dwRet := MapiLogon(Handle,
nil,
nil,
MAPI_DIALOG or MAPI_NEW_SESSION,
0, #MAPI_Session);
I tried with "MAPISend component", this code:
http://prog.hu/tudastar/60044-6/Delphi-Email+csatolt+file+thunderbird.html
and 2 of others.
Interesting, that Acrobat Reader CAN use the MAPI with Attach to email function, and the "Send" "In Mail" context menu also working.
I don't understand why it isn't working, in my machine (Win7) it is working fine.
Then machines where I failed have WinXP OS, and they used Thunderbird.
What I can do to successfully logon into MAPI?
THanks:
dd
I think I found the problem.
The problem, that Delphi needs a Registry value named MAPI under
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Messaging Subsystem"
If this not present, it send 1 error code to you what is the base of the confusion.
This value must be string. The sysadmin wrote DWORD, and this caused the problem.
Thanks for your help:
dd
I am using RapWare components, http://www.rapware.nl/
Hth's.
Stanko.
I'm not sure about any Delphi-specific issues, but you don't need to call MAPILogon before calling MAPISendMail. If you do, I wouldn't check the return value. That's why Acrobat Reader was working and your SMAPI client was not.
Related
Hi I am using LabView 2012, Delphi XE7 and GPIB (I think 488.2), Win7 SP1 and Agilent 53131A.
I used the given NI examples.
NI Labview example - Found in LabVIEW's help - GPIB.vi.
I tried writing and reading to query frequencies from 2 channels and they are successful.
They are are sent and read in succession.
*IDN?
:FUNC 'FREQ 1'
:READ:FREQ?
If they are successful, that meant GPIB for Agilent and NI MAX and driver are successfully installed and configured.
I am also able to use KeySight Connection Expert's to write and read, Again it is also successful.
However, When I used the given NI example in Delphi. Orginally it was saved as Delphi 3 or 4.
I used the Scope Simple example for universal counter. I used it mostly for writing and reading in the simple way. All it needs initialization, read/write and cleanup
I changed the following codes as shown below, in SimpleForm.pas
The detected device is at GPIB0::3::INSTR so, at line 32,
PRIMARY_ADDR_OF_COUNTER = 3;
String to write and read so, at line 132,
CommandBox.Text := '*IDN?';
then it was compiled with no error and run.
String to write was successfully
But upon reading, it was not successfully.
The string output is supposed to be ' HEWLETT-PACKARD,53131A,0,4806'.
The error at the end of the program is as follows below:-
Unable to read from device
ibsta = SC000 <ERR TMO>
iberr = 6 <EABO>
ibcntl = 0
From these readings, I figured out as :-
EABO means abort
I am not familiar with working of GPIB. Kindly advise.
You are correct that EABO is the identifier for an abort. In addition, we can see from ibsta = SC000 <ERR TMO> that the cause of the abort was a GPIB timeout error. I am not familiar with Keysight Connection Expert or your instrument, but since the error was from GPIB timeout, the most likely causes are:
The query was improperly formatted and the instrument thought it was just a write statement with no response needed. (That's probably why the write function had no error, but the read function timed out.)
The query was improperly formatted and the instrument returned an error.
Instrument needs to have 'Talker' capability enabled to send data. (Most instruments do this automatically with queries.)
For more information on generic GPIB commands, see this reference from the folks at National Instruments.
One of my users at a large university (with, I imagine, the aggressive security settings that university IT departments general have on their computers) is getting an empty string returned by Windows XP for CSIDL_COMMON_APPDATA or CSIDL_PERSONAL. (I'm not sure which of these is returning the empty string, because I haven't yet examined his computer to see how he's installed the software, but I'm pretty sure it's the COMMON_APPDATA...)
Has anyone encountered this or have suggestions on how to deal with this?
Here's the Delphi code I'm using to retrieve the value:
Function GetSpecialFolder( FolderID: Integer):String;
var
PIDL: PItemIDList;
Path: array[0..MAX_PATH] of Char;
begin
SHGetSpecialFolderLocation(Application.Handle, FolderID, PIDL);
SHGetPathFromIDList(PIDL, Path);
Result := Path;
end; { GetSpecialFolder }
ShowMessage(GetSpecialFolder(CSIDL_COMMON_APPDATA)); <--- This is an empty string
Edit:
Figuring out this API made me feel like I was chasing my tail - I went in circles trying to find the right call. This method and others similar to it are said to be deprecated by Microsoft (as well as by a earlier poster to this question (#TLama?) who subsequently deleted the post.) But, it seems like most of us, including me, regularly and safely ignore that status.
In my searches, I found a good answer here on SO from some time ago, including sample code for the non-deprecated way of doing this: what causes this error 'Unable to write to application file.ini'.
If you want to find out why an API call is failing you need to check the return values. That's what is missing in this code.
You need to treat each function on its own merits. Read the documentation on MSDN. In the case of SHGetSpecialFolderLocation, the return value is an HRESULT. For SHGetPathFromIDList you get back a BOOL. If that is FALSE then the call failed.
The likely culprit here is SHGetSpecialFolderLocation, the code that receives the CSIDL, but you must check for errors whenever you call Windows API functions.
Taking a look at the documentation for CSIDL we see this:
CSIDL_COMMON_APPDATA
Version 5.0. The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All
Users\Application Data. This folder is used for application data that
is not user specific. For example, an application can store a
spell-check dictionary, a database of clip art, or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is
available to anyone using the computer.
If the machine has a shell version lower than 5.0, then this CSIDL value is not supported. That's the only documented failure mode for this CSIDL value. I don't think that applies to your situation, so you'll just have to see what the HRESULT status code has to say.
I have this line of code in my Delphi app:
sh := CoShellWindows.Create;
When run through a Citrix session, this raises an exception "Not enough storage is available to complete this operation."
Can someone confirm my suspicion that I can't access this through Citrix? I'm running in Seamless mode if that makes any difference. Maybe there's something I need to change on the published icon to make it work?
I am guessing that there is no "Shell" in Citrix to create.
Thanks
EDIT
The CoShellWindows is simply a class which creates an object which implements the IShellWindows interface. This interface is then used to iterate through it's items looking for an instance of Internet Explorer (or more specifically, an item which implements the IWebBrowser2 interface).
There are a few other use case scenarios using the CoShellWindows, but all ultimately are used to interact with the IWebBrowser2 interface (Internet Explorer 8). My requirement is to obtain this IWebBrowser2 object.
The call, behind the scenes is calling the Windows API CoCreateInstance with the following parameters:
rclsid = {9BA05972-F6A8-11CF-A442-00A0C90A8F39} (CLSID of
IShellWindows)
pUnkOuter = null (nil)
dwClsContext = CLSCTX_ALL (I've tried various combinations of these
flags)
riid = {85CB6900-4D95-11CF-960C-0080C7F4EE85} (IID of IShellWindows)
ppv = a variable declared as type IShellWindows
eg:CoCreateInstance(CLASS_ShellWindows, nil, CLSCTX_ALL, IID_IShellWindows, sh)
Your exception "Not enough storage is available to complete this operation." should really read "Shell does not exist so no instance can be created"
Basically you are correct in your assumption that there is no shell to create in Citrix.
What are you using the shell for? as if you provide more information we may well be able to offer a full work around.
Delphi 2007 on windows 7 just does nothing on the saveDialog.Execute call. I have seen another person mention this a few weeks back but it was with Borland c++.
See the thread "TOpenDialog.Execute not working " on embarcadero newsgroups.
Problem there was resolved by deleting the executable name from
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options"
I got the same problem (savedialog not working) in windows XP.
After lots of unsuccessful attempts according to the voluminous exchanges in the embarcadero group you mention (https://forums.embarcadero.com/thread.jspa?messageID=196950&tstart=0#196950).
I found what the reason was : the initial file dir and filename of the Savedialog12 were bad, contradicting each other, the filename containing the fullpath of the last file I had opened (I had thought it was smart to prepare the saving of the file I had opened last; unfortunately what I had put in the initialdir was equal to what I had put in the filename !)
The problem was already solved by clearing both fields of the save dialog.
Further, my initial goal to prepare the saving was reached by putting valid values in the involved fields :
SaveDialog1.FileName:=ExtractFileName(Opendialog1.Filename);
SaveDialog1.InitialFileDir:=ExtractFilePath(Opendialog1.Filename);
I have the following automation code:
lPrintSetup := fWordObject.Application.Dialogs.Item(wdDialogFilePrintSetup);
lPrintSetup.Printer := 'MyPrinter';
lPrintSetup.DoNotSetAsSysDefault := True;
lPrintSetup.Execute;
lPrintSetup := Null;
The Printer property is giving me some problems, sometimes Execute crashes with an EOleException (0x800A1460 (error code 5216): There is a printer error) because of a wrong printername.
I have printer information of all printers in a _PRINTER_INFO_2 record which I obtained by a EnumPrinters API-call. How can I compose the right printername for Word given the information in a _PRINTER_INFO_2 record? It has work with at least Windows 2000, Word 2000 and Citrix.
Some background info:
Our application first filled the Printername with a self constructed printername. This gave problems with Citrix clients, so for Citrix clients we took the _PRINTER_INFO_2.pPortName and deleted the Client:#: part.
This is working for the majority of our customers, but sometimes still the printer error shows up.
What I have tried so far (on Windows XP SP3, Word 2007):
Just take the _PRINTER_INFO_2.pPrinterName. Problem is that when you modify printernames on purpose (renaming 'PDFCreator' to 'HP DESKJET 520 on MYPC') it crashes on the latter (while selecting this printer in Word works).
Composing a printername like this: lPrintSetup.Printer := PRINTER_INFO_2.pPrinterName + ' on ' + PRINTER_INFO_2.pPortname. Seems to work always! But googling around showed that ' on ' is localized, so I'm not sure if that's going to work on non-english Windows versions. Edit: does not work always :(
Another solution I found on the web:
When reading the printername from Word it has the form of "Printername on Ne01:", where Ne01 is ranged from Ne00: to Ne99:. The solution suggested taking the printername and just try to set it while looping from Ne00: to Ne99:. When .Execute doesn't crash, you've got the right one. I'm not very fond of this 'trail and error' method.
I'm not sure if you've tried this, or if its of any use, but you can get a list of all the printers on the system from the Printer.Printers object make sure you add Printers to the Uses clause of your unit.
This should then list the actual names on the system and you may be able to use this information to do what you want.
As stated you can get a list of printer names using the Printer.Printers which is a TStringList with the name of the printer on each item.
This code gives the default printer name
Printer.Printers[Printer.PrinterIndex]
Some minutes ago I learned, that word2k not only wants Printernames like "Printername on Ne01:" it only wants the port (NEnn) uppercase "Printername on NE01:"
I figured it out. Word has the printername in the form of "Printername on NE01:". Ne01: is the printerport as specified in the devices section of win.ini. So now I compose the printername as _PRINTER_INFO_2.pPrinterName + ' on ' + <PrinterPort from win.ini> and set that name for the printer property of the FilePrintSetup dialog.
This is much better than to resort to the trail-and-error method mentioned in my question.