Forum Replies Created
-
Posts
-
In AC 15.05, it’s still calling OnAcceptDate for all dates 3 times. The less intrusive calls are now eliminated, I would preferred it the other way around.
PS. The AC 13.05 in the topic header should be AC15.03
Very simple to build this yourself:
procedure SetActiveTab(PC: TsPageControl; PageNr: Integer); var Accept: Boolean; begin PC.OnChanging(PC, Accept); if not Accept then Exit; PC.ActivePageIndex := PageNr; PC.OnChange(PC); end;Can you explain which problem this change solves that is not handled by the OnChanging and OnChange events?
Hello
Do you use the ShowPopupForm procedure for showing of the form?
Which components are placed there? Which control shows a text?No, Guido means the standard Windows dialogs, when SkinManager.SkinningRules.srStdDialogs = True. And in fact Office 2007 Black is the only one that’s problematic. So it’s a skin problem.
This is a silly setup I have. The help window must stay, until manually closed by the user. Even if the popup window is long gone.
The only thing I can think of is special coding to prevent the popup screen from closing if focus went to that help screen. But it’s totally OK if focus went to a window different from that help window. In that case the help window should stay open however.
So it is definitely not just a simple flag.I think, using of the OnCloseQuery event may help in this case.
No, it does not. After the help screen is created, it’s pretty much on its own. It is not related in any way any more to the window that created it. So there’s nothing to test in OnCloseQuery.
The HTML help screen is totally separate from the rest of the application. It stays visible until the help screen itself is closed. So any activity on this help screen (like scrolling the text) should not close the popup screen, but activity on other parts of the application should close the popup screen.
Maybe these requirements are too conflicting.There are 5 occurrences of HWND_TOPMOST in that module. I don’t think it is a good idea to change all of them. After all, you must have had a good reason to put them there.
I know this hWndInsertAFter parameter may cause problems if not used correctly (like a windows not showing at all). So, I’m not feeling OK about this.
There may be another way of going about this. Maybe you could use HWND_TOPMOST only if project is not being run in the Delphi debugger. That would give the best of both worlds.So, in the initialization of the acPopupController have code like this:
if System.DebugHook = 0 then hWndInsertAfter := HWND_TOPMOST else hWndInsertAfter := HWND_TOPThe popup in question is viewable in #86507
The popup form contains a help button which will produce a HTML help screen. But in doing so, closes the popup form.This is a better view on the problem.
It’s part of the screen with the expolorer on it. But, because the popup window’s process is in suspended state by the Delphi debugger, I cannot get rid of it. It seems to think it has to be on top always.I’m not sure which parameters.
What happens is that the popup window monopolizes the mouse cursor, although it is not visible.
Try this:
Make a project with a popup window.In the form of the popup window set a breakpoint. Run the project in the debugger until it hits the breakpoint. Now switch to another program, let’s say the explorer. Try to select a file that is in the same area as the popup window (now hidden) is. It is not possible.I don’t know. You see that the message is 2 hours off. The server should take care of the time zone. Best by storing messages in universal GMT time and compensating when showing it.
I don’t know if you see the same thing. My message header says: “Februari 8, 2020 at 2:08 pm”. But in local time it was posted at 12:08 pm.
