Looking to get my delphi app to log into a website, navigate to a page, and automatically download certain files, the solution at How do I keep an embedded browser from prompting where to save a downloaded file?, helped a great deal with the file download.
The final problem is the last step on navigating opens in a popup window, there are plenty of solutions out there to capture popup windows by implementing TWebBrowser.NewWindow2 but none of these events seem to work with the above code, something to do with how twebbrowser.invokeevent in the above code works maybe?
If I use invokeveent and the dispID of 273(newwindow3) to call a function I can twebbwowser.navigate() a second webbrowser to the url of the popupwindow.
My problem is the popup window has basicly one line of javascript "document.print(parent.parent.opener.thefunction())" the second twebbrowser has no reference to its parent so this fails.
I can see two possible solutions, get the TWebBrowser.NewWindow2 or 3 to trigger, fix the code sample bellow, LVarArray[0] {const IDispatch}, is null for some reason.
procedure TWebBrowser.InvokeEvent(ADispID: TDispID; var AParams: TDispParams);
// DispID 250 is the BeforeNavigate2 dispinterface and to the FFileSource here
// is stored the URL parameter (for cases, when the IDownloadManager::Download
// won't redirect the URL and pass empty string to the pszRedir)
//showmessage('test');
var
ArgCount : Integer;
LVarArray : Array of OleVariant;
LIndex : Integer;
begin
inherited;
ArgCount := AParams.cArgs;
SetLength(LVarArray, ArgCount);
for LIndex := Low(LVarArray) to High(LVarArray) do
LVarArray[High(LVarArray)-LIndex] := OleVariant(TDispParams(AParams).rgvarg^[LIndex]);
case ADispID of
250: FFileSource := OleVariant(AParams.rgvarg^[5]);
273: DoNewWindow3(Self,
LVarArray[0] {const IDispatch},
WordBool((TVarData(LVarArray[1]).VPointer)^) {var WordBool},
LVarArray[2] {const OleVariant},
LVarArray[3] {const OleVariant},
LVarArray[4] {const OleVariant});
end;
end;
I'm not going to answer your question directly because I think you've asked the wrong question. You are trying to download files over the internet without any GUI being shown to the user. As such, an embedded browser is simply the wrong solution.
Rather than trying to suppress popup dialogs, use a tool that never shows popup dialogs. What I believe you should be doing is downloading the files using direct HTTP download. There are many different ways to achieve that. For example, an extremely convenient method, available out of the box with Delphi, is to use Indy. I believe that the component you need is TIdHttp.
Related
I changed for Delphi 10.3 and its default TOpenDialog contains a preview pane. I made some searches and found the IFileDialogCustomize interface provided by Microsoft to customize standard WinAPI dialogs. I know I have to use the OnSelectionChange event handler to modify the picture of the pane. The big question for me is : how can I access the preview pane image by IFileDialogCustomize? What is the ItemID for this? I couldn't find any answer to this question on the net. Somebody know the answer? Then please share with me and the community! :)
I replaced some code fragments by ... for the sake of brevity, because these are trivial or app dependent sections.
procedure TMainWindow.OnSelectionChange( Sender : TObject );
var
dc : HDC;
aBMP : TBitmap;
function isSelectedFilePreviewAble : boolean;
begin
result := ...;
end;
functon getPreviewPictureDC : HDC;
var
iCustomize : IFileDialogCustomize;
h : THandle;
begin
if OpenDialog1.QueryInterface( IFileDialogCustomize, iCustomize ) = S_OK then
begin
h := iCustomize.??? this is the missing code fragment
result := GetDC( h );
end else
result := 0;
end;
procedure generatePreviewPicture;
begin
...
end;
begin
dc := getPreviewPictureDC;
if ( dc <> 0 ) then
begin
aBMP := TBitmap.Create;
try
if ( isSelectedFilePreviewAble ) then
generatePreviewPicture;
StretchBlt( aBMP.Handle, ...);
finally
aBMP.Free;
ReleaseDC( dc );
end;
end;
end;
I made some searches and found the IFileDialogCustomize interface provided by Microsoft to customize standard WinAPI dialogs.
First, IFileDialogCustomize does not "customize standard WinAPI dialogs". It customizes only IFileOpenDialog and IFileSaveDialog dialogs, no others.
Second, TOpenDialog primarily uses the legacy Win32 API GetOpenFileName() function. On Windows Vista+, GetOpenFileName() uses IFileOpenDialog internally with basic options enabled, so that legacy apps can still have a modern look.
Although, under the following conditions, TOpenDialog will instead use IFileOpenDialog directly rather than using GetOpenFileName():
Win32MajorVersion is >= 6 (Vista+)
UseLatestCommonDialogs is True
StyleServices.Enabled is True
TOpenDialog.Template is nil
TOpenDialog.OnIncludeItem, TOpenDialog.OnClose, and TOpenDialog.OnShow are unassigned.
But even so, TOpenDialog still does not give you access to its internal IFileOpenDialog interface, when it is used.
If you really want to access the dialog's IFileOpenDialog and thus its IFileDialogCustomize, you need to use TFileOpenDialog instead of TOpenDialog (just know that dialog won't work on XP and earlier systems, if you still need to support them).
The big question for me is : how can I access the preview pane image by IFileDialogCustomize?
You don't. The preview pane is not a dialog customization, so it can't be accessed via IFileDialogCustomize. Even if you could get a control ID for the preview pane (which you can't), there is no function of IFileDialogCustomize that would allow you to access the preview pane's HWND or HDC, or otherwise alter the content of the preview pane in any way. The preview pane is an integral and private component of IFileDialog for any file type that supports previews. It is not something that you can access and draw on directly. IFileOpenDialog itself will update the preview pane as needed when the user selects a file that has (or lacks) a preview to display.
My boss want to show previews for our own file formats.
The correct way to handle that on Vista+ is to create a Preview Handler for your custom file types. Then, any Shell component that wants to display previews of your files, including IFileOpenDialog, can use your handler.
My Delphi application includes a help file that the user can call from anywhere in the application (well... that is, for all the parts I've written so far...)
It also includes the ability for the user to switch from the regular style to another VCL style from a list.
When no style is applied, the help file displays normally like this :
But as soon as a VCL style is active, the Help file does not display correctly anymore, like this :
Is this due to the way I declare the HelpFile on main Form creation like this (path being a global variable pointing to the main exe folder):
Application.HelpFile := path+'Help\D.R.A.M.A. 2.0 Help.chm';
or is this a known problem that can not be solved ?
SIDE NOTE : the help is called on helpContext should that be important to mention and the HtmlHelpViewer is added to the uses clause.
This answer was taken from https://forums.embarcadero.com/thread.jspa?threadID=227785 and I've confirmed works very well.
Drop a TApplicationEvents component onto the applications main form.
Implement the OnHelp event of that component as this:
function TfmMain.ApplicationEvents1Help(Command: Word; Data: NativeInt; var CallHelp: Boolean): Boolean;
begin
CloseHelpWnd;
Result := ShellExecute(0,'open','hh.exe',
PWideChar('-mapid '+IntToStr(Data)
+' ms-its:'+Application.HelpFile),
nil,SW_SHOW) = 32;
CallHelp := false;
end;
On the main form, implement the CloseHelpWnd method as this:
procedure TfmMain.CloseHelpWnd;
var
HlpWind: HWND;
const
HelpTitle = 'Your help file title';
begin
HlpWind := FindWindow('HH Parent',HelpTitle);
if HlpWind <> 0 then PostMessage(HlpWind,WM_Close,0,0);
end;
You would replace 'Your help file title' with the title of your help file. This is the window caption title when you open the help file directly.
In the FormDestroy event for the main form, include a call to
CloseHelpWnd;
So far we've not seen any issues with the above method, and because we are running the help file in a separate process, it is not affected by the VCL Styles problems evident in Delphi 10.2 Tokyo.
NOTE: It does not have to be the applications main form, but it must be a form that is created before the help system is needed and remains instantiated while the application is running. In our case, we did it on a common resources form and then all programs we rebuilt with the new form had the help problem resolved.
NOTE: You still need to set the Application.HelpFile property as normal, but you don't need to include the HtmlHelpViewer unit in the Uses clause.
I'm working on a software to verify the problem of porting it from D5 to XE5. In D5, TWebBrowser.BeforeNavigate2 was call each time the user click on the submit button of a displayed form. In XE5, it's not the case. I figured out it is because the URL for the submit contain http:/aDirectory/ExecToBeCall.exe. If I add an extra / after: the event is fire.
Under D5 the URL is change for:
http ://localhost/aDirectory/ExecToBeCall.exe (space added to break the link in the post)
That behavior of TWebBrowser under D5 to fire anyway and change the URL is important for the software and I cannot change the HTML (about 2000 files) to contain 2. It allowed us to know if the submit was made inside Delphi or from a outside Browser. I tried other and newer events of TWebBrowser and none are fire.
How can I be informed of a problematic URL, check it and change it into a localhost URL? A small and clean method would be preferable.
Thanks for your help and suggestions
TWebBrowser is just a thin wrapper around Internet Explorer's ActiveX object, so it is IE itself, not TWebBrowser, that is behaving differently.
http:/aDirectory/ExecToBeCall.exe is actually a valid URL. Since the : is not followed by //, there is no authority portion in the URL, and thus no explicit hostname. localhost is used as an implicit hostname, and the path is /aDirectory/ExecToBeCall.exe. That is what the URL is being changed to in D5, which is correct behavior. Changing the URL to http://aDirectory/ExecToBeCall.exe is incorrect, as that creates an authority portion of the URL and thus the hostname is explicitly set to aDirectory and the path is set to /ExecToBeCall.exe, which is not what you want.
Why the URL is not changing in XE5, I have no clue. Sounds like a bug in whatever version of IE is being used in that version of TWebBrowser.
In any case, it is IE that is triggering the event, so if it is not triggering for a URL it does not like, there is nothing you can do about that, short of using the browser's DOM interfaces to handle the onsubmit event of the HTML webform directly.
If you want to redirect unexpected url instead of navigating to it, you can start with TEmbeddedWB project or you can DIY by extending TWebBrowser class with IDocHostUIHandler, which has an interesting method TranslateURL.
function TAdvWebBrowser.TranslateURL(const dwTranslate: DWORD; const pchURLIn: POLESTR; var ppchURLOut: POLESTR): HRESULT;
var
Url: string;
BufferSize: Integer;
begin
Url := PChar(pchURLIn);
if GetSafeUrlFor(Url) then
begin
ppchURLOut := CoTaskMemAlloc(BufferSize);
CopyMemory(ppchURLOut, PChar(Url), BufferSize);
// redirects to new location
Result := S_OK;
end
else
// no redirection
Result := S_FALSE;
end;
// You can change the function to add more complex redirection rules
function GetSafeUrlFor(var Url: string): Boolean;
begin
Result := Url.EndsWithText('.exe');
if Result then
Url := 'http://localhost/';
end;
I have an application that mimics Windows Explorer, it uses a TcxShellListView amongst other shell controls.
A really nice feature would be to be able to Copy & Paste and Cut & Paste files between the real Windows Explorer and my application.
Drag & Drop already works out of the box, but it seems that DevExpress hasn't implemented the clipboard side, yet.
Any Ideas?
If you want to implement the copy/paste yourself, the mechanism is almost identical to drag and drop. The drag and drop code that you have will create an IDataObject. To copy, instead of calling DoDragDrop to initiate a drag, simply call OleSetClipboard passing the IDataObject. And for pasting you call OleGetClipboard to get the IDataObject from the clipboard. And then you simply use the exact same code as for a drop operation to decode the IDataObject. That's all there is to it.
There is another way to do it, probably a better approach in my view. And that is to use IContextMenu to do the work. And example of this can be found in the TurboPower tpShellShock project. Have a look for ShellMenuExecute in the StShlCtl unit. So long as the DevExpress component is using the shell interfaces, i.e. IShellFolder, then you will be able to use that same approach. The advantage of this shell based approach is that you are getting the shell to do the work. If a copy dialog needs to be shown, then the shell will do so. This will give you the most integrated user experience.
This code looks like this:
procedure ShellMenuExecute(
const Sender : TObject; const Folder : IShellFolder;
var Pidl : PItemIDList; const Count : Integer;
const AHandle : THandle; ClipboardAction : TStMenuAction);
var
CM : IContextMenu;
CI : TCmInvokeCommandInfo;
begin
if Folder <> nil then begin
if (Folder.GetUIObjectOf(AHandle, Count, Pidl,
IID_IContextMenu, nil, Pointer(CM)) = NOERROR)
then begin
ZeroMemory(#CI, SizeOf(CI));
CI.cbSize := SizeOf(TCmInvokeCommandInfo);
CI.hwnd := AHandle;
case ClipboardAction of
caCut : CI.lpVerb := 'cut';
caCopy : CI.lpVerb := 'copy';
caPaste : CI.lpVerb := 'paste';
caProperties : CI.lpVerb := 'properties';
end;
CM.InvokeCommand(CI);
CM := nil;
end;
end;
end;
I think you should be able to use this code pretty much as is. I would point out that the handle parameter is declared incorrectly. It should be HWND. It's used as the owning window for any dialog that is shown during the call to InvokeCommand.
This refer to the post Delphi SOAP Envelope and WCF.
Could someone please post a sample code which can show me how to set soLiteralParams in THTTPRio.Converter.Options in Delphi 7. I have the following code currently.
I have drag-dropped a HTTPRIO component into the document which has created a line HTTPRIO1: THTTPRIO at the beginning of the code. I basically want to understand how I set soLiteralParams in the above component. Following is the code I am trying to execute which is giving me error.
procedure TForm1.CleanUpSOAP(const MethodName: String; var SOAPRequest: WideString);
var RIO: THTTPRIO;
begin
//The following line is giving error
// RIO.Converter.options := [soLiteralParams];
end;
In the above code I have declared a variable RIO of the type THTTPRIO, which I am not sure is correct.
Just guessing, as you provide very little information in your question.
Use the variable assigned to the component you dropped on your form. Don't declare a new local one (which you never created anyway). To set the Converter.Options in code, you'll need to add OPToSOAPDomConv to your uses clause.
implementation
uses
OPToSOAPDomConv;
// BTW, this name might not be a good one if it's the
// OnBeforeExecute event handler as that isn't
// clear from the name.
procedure TForm1.CleanUpSOAP(const MethodName: String; var SOAPRequest: WideString);
begin
// Note this clears any previous options!
HTTPRIO1.Converter.Options := [soLiteralParams];
// If you want to keep the previous options instead of replacing them
// HTTPRIO1.Converter1.Options := HTTPRIO1.Converter1.Options + [soLiteralParams];
end;
If you've dropped the component on the form, I'm not sure why you're not handling this in the Object Inspector instead, however.
If this doesn't solve the problem, edit your question and provide the exact error message you're receiving, including any memory addresses in the case of an exception being raised.
I have cracked this. The issue was that I didn't refer to OPconvert.pas file, which contained the TSOAPConvertOption enumeration. I don't know whether copying this file into the same folder as my project files and referring to this in the "uses" section is the right way, but it worked fine.