I forgot to mention that I had to add
C:\Program Files (x86)\Embarcadero\Studio\18.0\source\fmx
to
Project | Option... | Delphi Compiler | Search path

So, this isn't really a solution, just a workaround.

Read More...

Here's what I did that got the "Find Declaration" support working correctly:

1) I changed
Project | Option... | Delphi Compiler | Compiling | Debugging:
Symbol reference info
to "Definitions Only".
2) Pressed "OK".
3) Reopened Project | Options and changed "Symbol reference info" back to "Reference info". Pressed "OK".
4) Rebuilt my project.

Hope this helps anybody else who runs into the same problem.

Read More...

Has anybody else noticed any differences or problems with Code Insight /Code Completion in RadStudio/Delphi Berlin?
If I right click on an identifier and choose "Find Declaration", the IDE no longer works as in earlier versions (eg, Seattle).
"Find Declaration" will work as before only if the identifier is defined within that file.
Otherwise nothing.

Were any IDE settings changed with Berlin that might be affecting this?

Thanks,

Dan

Read More...

Marco,
I found an old edn account that gave me access to the quality report.

Yes, I think it's the same problem.

It's a serious bug, because it means that practically any program that has a TWebBrowser will get an access violation, even if the browser object isn't in the current form and even if it's form has never been shown.
In my example, all you need to get the access violation is to click on any (main menu or popup menu) menu item. Just the act of the menu closing (actually, the menu's underlying FireMonkey form) will cause the message to be sent that invokes FormHandleDestroyed on any TWebBrowser objects.

Dan

Read More...

Marco,

I get a message saying I don't have access when I follow the link for quality.embarcadero.com, so I don't know if it has been reported elsewhere.

In my usage, adding the two lines to the two procedures addresses the issue, so the question comes down to:
is there really a reason why the webbrowser object needs to receive this message for all forms?

Dan

Read More...

Evidently, the problem is with FormHandleDestroyed

I'm still not sure what the web browser object needs to receive a message every time a form handle is destroyed (in this case, because of the form ('CustomPopupForm') underlying a popup menu closes).

There probably should be a check at the top of FormHandleDestroyed that Sender is in fact the form that owns the web browser object.

Hmmm... and a similar test needs to go to the top of FormHandleCreated as well.

Thoughts, anyone????

FMX.WebBrowser.pas fix:

procedure TCustomWebBrowser.FormHandleDestroyed(const Sender: TObject; const Msg: TMessage);
var
WBService : IFMXWBService;
begin

if Sender <> Self.Root.GetObject then

Exit;

Read More...

I have a Delphi/Seattle FireMonkey project that runs with no problems that I've just moved to Berlin. After a clean build, I now get an access violation when run as Win32 or Win64. More specifically: 1) The problem occurs if the application includes a form that has a TWebBrowser. If that form is not created by the application, then the access violation does not occur. 2) The problem occurs in TCustomWebBrowser.FormHandleDestroyed in FMX.WebBrowser.pas. (FormHandleDestroyed and FormHandleCreated are evidently new procedures added with Berlin). 3) The problem occurs with the line FURL := FWeb.URL; as FWeb is nil and there is no check against this member being nil.

4) Invoking any menu item on a form results in the access violation (the form with the TWebBrowser has not even been used and is not visible).

5) Here's the bottom of the stack trace when the access violation occurs:

FMX.WebBrowser.TCustomWebBrowser.FormHandleDestroyed(???,???) System.Messaging.TMessageManager.TListenerList.IterateAndSend($50C3A5,$19FB70) System.Messaging.TMessageManager.TListenerList.SendMessage($5E70E30,$8983220) System.Messaging.TMessageManager.SendMessage($5E70E30,$8983220,True) FMX.Forms.TCommonCustomForm.DestroyHandle FMX.Forms.TCustomForm.DestroyHandle FMX.Forms.TCommonCustomForm.Recreate FMX.Forms.TCommonCustomForm.HandleNeeded FMX.Forms.TCommonCustomForm.Show Listings.TListingsForm.ActionItemDetailsExecute($5E906B0) System.Classes.TBasicAction.Execute FMX.ActnList.TCustomAction.Execute System.Classes.TBasicActionLink.Execute(???) FMX.Controls.TControl.Click FMX.Menus.TMenuItem.Click FMX.Menus.TClickList.DoClicks($88DE250) FMX.Types.TTimer.DoOnTimer FMX.Types.TTimer.Timer FMX.Platform.Win.TimerCallBackProc(0,275,25782,3462593) :73e884f3 user32.SetManipulationInputTarget + 0x53 :73e644f7 ; C:\WINDOWS\SysWOW64\user32.dll :73e6661f ; C:\WINDOWS\SysWOW64\user32.dll :73e66300 user32.DispatchMessageW + 0x10 FMX.Platform.Win.TPlatformWin.HandleMessage :00894704 Fmx::Platform::Win::TPlatformWin::HandleMessage(Self=????) FMX.Platform.Win.TPlatformWin.Run FMX.Forms.TApplication.Run

Does anybody have any suggestions as to a workaround to this problem?

I could probably add a check to see if FWeb is nil, but the problem more likely has to do with the reason that FormHandleDestroyed() is being called.

Thanks for the help, in advance,

Dan

Evidently, the problem is with [size= 12.16px; line-height: 15.808px]FormHandleDestroyed.[/size]

[size= 12.16px; line-height: 15.808px]I'm still not sure what the web browser object needs to receive a message every time a form handle is destroyed (in this case, because of the form ('CustomPopupForm') underlying a popup menu closes).[/size]

There probably should be a check at the top of FormHandleDestroyed that Sender is in fact the form that owns the web browser object.

Hmmm... and a similar test needs to go to the top of FormHandleCreated as well.

Thoughts, anyone????

Similar (not quite correct) fix for now:

procedure TCustomWebBrowser.FormHandleDestroyed(const Sender: TObject; const Msg: TMessage);
var
WBService : IFMXWBService;
begin
if Sender <> Self then // <-- Add This Line; this is a quick and dirty fix. The test should really be on the form that owns the web browser instance.
Exit; [size= 12.16px; line-height: 15.808px]// <-- Add This Line[/size][size= 12.16px; line-height: 1.3em] [/size]

Read More...

I have a Delphi/Seattle FireMonkey project that runs with no problems that I've just moved to Berlin.
After a clean build, I now get an access violation when run as Win32 or Win64.

More specifically:

1) The problem occurs if the application includes a form that has a TWebBrowser.If that form is not created by the application, then the access violation does not occur.

2) The problem occurs in TCustomWebBrowser.FormHandleDestroyed in FMX.WebBrowser.pas.
[size= 12.16px; line-height: 15.808px](FormHandleDestroyed and [/size]FormHandleCreated are evidently new procedures added with Berlin).

3) The problem occurs with the line
FURL := FWeb.URL;
as FWeb is nil and there is no check against this member being nil.

4) Invoking any menu item on a form results in the access violation (the form with the TWebBrowser has not even been used and is not visible).

5) Here's the bottom of the stack trace when the access violation occurs:
FMX.WebBrowser.TCustomWebBrowser.FormHandleDestroyed(???,???)
System.Messaging.TMessageManager.TListenerList.IterateAndSend($50C3A5,$19FB70)
System.Messaging.TMessageManager.TListenerList.SendMessage($5E70E30,$8983220)
System.Messaging.TMessageManager.SendMessage($5E70E30,$8983220,True)
FMX.Forms.TCommonCustomForm.DestroyHandle
FMX.Forms.TCustomForm.DestroyHandle
FMX.Forms.TCommonCustomForm.Recreate
FMX.Forms.TCommonCustomForm.HandleNeeded
FMX.Forms.TCommonCustomForm.Show
Listings.TListingsForm.ActionItemDetailsExecute($5E906B0)
System.Classes.TBasicAction.Execute
FMX.ActnList.TCustomAction.Execute
System.Classes.TBasicActionLink.Execute(???)
FMX.Controls.TControl.Click
FMX.Menus.TMenuItem.Click
FMX.Menus.TClickList.DoClicks($88DE250)
FMX.Types.TTimer.DoOnTimer
FMX.Types.TTimer.Timer
FMX.Platform.Win.TimerCallBackProc(0,275,25782,3462593)
:73e884f3 user32.SetManipulationInputTarget + 0x53
:73e644f7 ; C:\WINDOWS\SysWOW64\user32.dll
:73e6661f ; C:\WINDOWS\SysWOW64\user32.dll
:73e66300 user32.DispatchMessageW + 0x10
FMX.Platform.Win.TPlatformWin.HandleMessage
:00894704 Fmx::Platform::Win::TPlatformWin::HandleMessage(Self=????)
FMX.Platform.Win.TPlatformWin.Run
FMX.Forms.TApplication.Run


Does anybody have any suggestions as to a workaround to this problem?
I could probably add a check to see if FWeb is nil, but the problem more likely has to do with the reason that
FormHandleDestroyed() is being called.

Thanks for the help, in advance,

Dan

Read More...

Does anybody have any suggestions as to a WYSIWYG HTML editor that is a FireMonkey component?

The only thing I've seen is from FMXExpress but it's a bit pricey.

I've tried something simple myself, basically a tabcontrol with one tab a rich edit component and the other a memo showing the rich edit converted to HTML. Unfortunately, the translation of the text going back and forth between the two tabs does not work as well as I'd like. That's the reason I'm looking for some component for this.

Thanks,

Dan

Read More...