XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
|
Sabrina Horst
Previous versions (v9, UP) I would use the activex-webbrowser to preview documents (pdf f.e.)
XPA does not allow activex so I altered the preview to the .Net webbrowser (SWF.Webbrowser). There is a difference in behavior. While scrolling through a table with an activex preview of pdf on the side, you can go row by row down and activex will display content but not park on it. Same program but with . Net: It parks every time on the .net control. Behavior I do not want, it is only for display. Need to every time esc the control. Can I alter this with some setting or another way ? Thx Sabrina |
||||
|
|
||||
|
Frederik Soete
Hi, I do not have access to my XPA studio now, but after opening the form, then selecting the DotNet control properties, check if you can change 'allow park' or 'tab into' (near the bottom) to something more suitable. I hope those properties are available to you, and solve the parking problem. Bye, Frederik Soete Op 17 aug. 2017 09:27 schreef "Sabrina Horst" <s.horst@...>: Previous versions (v9, UP) I would use the activex-webbrowser to preview documents (pdf f.e.) |
||||
|
|
||||
|
Sabrina Horst
Thx Frederik. These I have already set to No.
Still problem of parking.
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Frederik Soete
Verzonden: donderdag 17 augustus 2017 17:01 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi,
I do not have access to my XPA studio now, but after opening the form, then selecting the DotNet control properties, check if you can change 'allow park' or 'tab into' (near the bottom) to something more suitable. I hope those properties are available to you, and solve the parking problem.
Bye,
Frederik Soete
Op 17 aug. 2017 09:27 schreef "Sabrina Horst" <s.horst@...>:
|
||||
|
|
||||
|
Frederik Soete
Hi, Since last I responded, I have briefly used your great idea of pdf viewing through the dot net control. I have seen that those properties are indeed lacking. You can try to work around that issue by replacing the webbrowser by a subform (that does have those properties I mentioned), and then putting the webbrowser in the subform. In that way I think it will work. Hope that helps, Frederik Soete Op 21 aug. 2017 08:45 schreef "Sabrina Horst" <s.horst@...>:
|
||||
|
|
||||
|
Sabrina Horst
Hi Frederik. Subform implemented, but same behaviour. As soon as the webbrowser.navigate(url) is done it will park and stay there.
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Frederik Soete
Verzonden: maandag 21 augustus 2017 12:13 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi,
Since last I responded, I have briefly used your great idea of pdf viewing through the dot net control. I have seen that those properties are indeed lacking. You can try to work around that issue by replacing the webbrowser by a subform (that does have those properties I mentioned), and then putting the webbrowser in the subform. In that way I think it will work.
Hope that helps,
Frederik Soete
Op 21 aug. 2017 08:45 schreef "Sabrina Horst" <s.horst@...>:
|
||||
|
|
||||
|
Frederik Soete
Hi Sabrina,
Hmm, after inspection, my program too had some lingering parking problems. I have now fixed the parking issue that I experienced on my end. My subform has a DotNet 'navigate' statement in task prefix. Supposing your subform has the same, try tweaking the End Task condition to 'Before' with expression 'SubformExecMode(0)<>0'. This means the task will end immediately unless the user sets focus to the pdf (which you may still want, e.g. for zooming and printing etc.). Bye, Frederik Soete |
||||
|
|
||||
|
Sabrina Horst
Thx Frederik
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Frederik Soete
Verzonden: dinsdag 22 augustus 2017 7:10 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi Sabrina,
|
||||
|
|
||||
|
Freddy Dewulf
Hi,
I have a similar problem with the .NET webbrowser control.
In component A, I have program A10. Program A10 is an online program with a subform.
This subform activates program B20 in component B. Program B10 is an online program with the .NET webbrowser control. In TP there is the navigate method in order to view the document in the webbrowser control. Program B10 : End task Before – Condition: SubFormExecMode(0) <>0.
When A10 is executed, program B10 executes 2 times. The first time SubformExecMode(0) = 1, so the program exits. The second time SubformExecMode(0) = 0, so the cursor parks on the webbrowser control.
I don’t understand why the program B10 is executed 2 times, without intervention of the user.
When I call B10 from within component B, then B10 is also executed 2 times, but the second time SubFormExecMode(0) =2 and the program exits.
Why oh why
Met vriendelijk groet – With kind regards Freddy Dewulf |
||||
|
|
||||
|
Frederik Soete
Hi Freddy, Won't be able to help you with that: as you may know, we have no experience with components, our application is a giant monolith, so to speak. We haven't used them in v9, and probably won't in XPA. So I hope someone else has the inspiration you need for the component situation... (By the way, Freddy, do you have any idea whether Magic Benelux has given up on the old idea of the so-called inspiration events as daytime events? Personally I'm not too keen to go to late developer meetings in 'faraway' Holland.) Vriendelijke groeten (friendly greetings), Frederik Soete Op 24 aug. 2017 13:46 schreef "Freddy Dewulf" <softica@...>:
|
||||
|
|
||||
|
Sabrina Horst
I don’t know Freddy. In my case it will not park anymore, but will not come back to its original control either. It looks like the cursor is ‘gone’. Monitor does not give a clue either.
I have given up and will not preview anymore. User has to really say ‘open’ before I show.
This has take up way to much time already.
Really bad idea to give up all the activex in XPA.
Sabrina
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Freddy Dewulf
Verzonden: donderdag 24 augustus 2017 13:46 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi,
I have a similar problem with the .NET webbrowser control.
In component A, I have program A10. Program A10 is an online program with a subform.
This subform activates program B20 in component B. Program B10 is an online program with the .NET webbrowser control. In TP there is the navigate method in order to view the document in the webbrowser control. Program B10 : End task Before – Condition: SubFormExecMode(0) <>0.
When A10 is executed, program B10 executes 2 times. The first time SubformExecMode(0) = 1, so the program exits. The second time SubformExecMode(0) = 0, so the cursor parks on the webbrowser control.
I don’t understand why the program B10 is executed 2 times, without intervention of the user.
When I call B10 from within component B, then B10 is also executed 2 times, but the second time SubFormExecMode(0) =2 and the program exits.
Why oh why
Met vriendelijk groet – With kind regards
Freddy Dewulf |
||||
|
|
||||
|
Frederik Soete
Hi,
Sorry that my earlier suggestions were not entirely helpful as I partially misunderstood Sabrina's program. My program does not apply a new URL on every record in the table, as I assume Sabrina's program does, but only when I press a button; so it was not entirely obvious to me that my bugfix would not work in the case that a new 'navigate' was triggered. So for that case there is still another bugfix possible, as suggested by generic help forums when looking for 'dot net webbrowser steals focus' (apparently a problem lots of developers have had, also outside of Magic). You can tweak the visibility of the DotNet control when navigating. Add a logical virtual to the subform task. If in task prefix, before the 'navigate', you set the virtual to false; then directly after the 'navigate', set it to true; and also apply the virtual as visibility condition to the DotNet control, the problem may disappear. Hope this indeed works for you both (Sabrina and Freddy). If not, I throw my hands in the air. Bye, Frederik |
||||
|
|
||||
|
Sabrina Horst
Thx Frederik. Very helpfull indeed!
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Frederik Soete
Verzonden: maandag 28 augustus 2017 13:01 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi,
|
||||
|
|
||||
|
achimmarx@...
Hi Sabrina,
I hope i have understand your problem correctly? I had proably the same Problem when migrating to xpa. I had to replace the activeX with a .net AxVSPDFViewerX from visasoft. I can't scroll in the table (upper task where the .net control was defined)) and in the subtask the preview didn't change. In the RP of the subtask the methods of .net were placed and then evaluate a ctrlgoto to the parkable variable in the upper task. Every time you change the record in the upper task it is necessary to clear the .net control. before entering the subtask. Best regards Achim Marx |
||||
|
|
||||
|
Sabrina Horst
Hi Archim
See first attachment-video
In my program I browse a table and every row has its preview. Scrolling to the next row it parks on the webbrowser control and stays there. My preview does get changed if I click with the mouse on the next row (so it parks there again). The ctrlgoto I tried to but did not work for me.
Then Frederic suggested to use a subform and I did but same behaviour.
Then I build it with the visible –construction in the subform. But still same behaviour (video 2).
I gave up. And now they have to open the preview with a button.
Sorry, cannot be of assistance as for me it is not solved too.
Sabrina
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens achimmarx@...
Verzonden: vrijdag 1 september 2017 10:18 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi Sabrina,
|
||||
|
|
||||
|
Frederik Soete
Hi Sabrina, My last suggestion only partially solved my situation, i guess depending on loading time, a bit randomly. The problem is widely known since long ago, but there is no elegant solution to the stealing of the focus. At least it cannot be easy in Magic. So as you say, it is best in your case to have the preview available by button only. (Unless we avoid the webbrowser entirely. Perhaps some other tool such as acrobat may be embedded that does not have the focus issue. But just as you, I have already spent too much time investigating something that is not actually worth it... So I won't go there...) Too bad that microsoft's control misbehaves. Bye, Frederik Soete Op 4 sep. 2017 10:45 schreef "Sabrina Horst" <s.horst@...>:
|
||||
|
|
||||
|
Sabrina Horst
Thx for trying to help Frederik. Much appreciated.
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io]
Namens Frederik Soete
Verzonden: maandag 4 september 2017 12:17 Aan: main@magicu-l.groups.io Onderwerp: Re: [magicu-l] XPA 2.5e system.windows.forms.webbrowser vs activex-webbrowser
Hi Sabrina,
My last suggestion only partially solved my situation, i guess depending on loading time, a bit randomly. The problem is widely known since long ago, but there is no elegant solution to the stealing of the focus. At least it cannot be easy in Magic. So as you say, it is best in your case to have the preview available by button only.
(Unless we avoid the webbrowser entirely. Perhaps some other tool such as acrobat may be embedded that does not have the focus issue. But just as you, I have already spent too much time investigating something that is not actually worth it... So I won't go there...)
Too bad that microsoft's control misbehaves.
Bye,
Frederik Soete
Op 4 sep. 2017 10:45 schreef "Sabrina Horst" <s.horst@...>:
|
||||
|
|
||||
|
Frederik Soete
Hi,
Maybe it is a bit late to come back to this old topic, but I have some new thoughts concerning the Adobe Acrobat Reader plugin for displaying PDFs within a DotNet webbrowser control. The problem Sabrina encountered when scrolling in a table and displaying a different PDF based on the current row, consisted of the table losing focus when the PDF was displayed in the webbrowser control. I now have some similar program for some of our clients, but this new program is based on the "GUI Frames" technique, since the user may want to resize the subforms in runtime. My particular GUI frames parent consists of three subforms (top-left: some PDF-files, bottom-left: some other entity, right: a webbrowser displaying the parked-on PDF-file). It seems that in this particular program the focus problem does not occur: when I scroll through the top-left table with PDF-files, refreshing the right-hand-side webbrowser using the filename from the top-left-tablerow, the top-left table does not lose focus, at least in our development environment. So, for anyone still interested in displaying PDFs alongside a table, maybe try the "GUI Frames" technique. It seems to resolve the issue on my end. Though, your mileage may vary. Good luck, Frederik Soete. |
||||
|
|
||||
|
Andreas Sedlmeier
So, for anyone still interested in displaying PDFs alongside a table, maybe try the "GUI Frames" technique. It seems to resolve the issue on my end. Though, your mileage may vary.I just noticed that I get depressions if I only read the word "GUI Frames". What you describe was exactly my plan for my demo framework - not for PDF but for the help system and then ... $$ Frames I only say ^^. Single User issue of today: UserFunctionality.edp you are not allowed to alter either :/ Andreas |
||||
|
|
||||
|
I tried to simulate this but I'm using XPA3.2 and the focus on the table is never lost.
|
||||
|
|
||||
|
Frederik Soete
Hmm, Thanks for your input. I am now running our applications in XPA 3.2 (d/e). With one internally used application, focus is *sometimes* (not always) lost to a normal subform with a webbrowser displaying a PDF. This was the case in the original thread in september. With another application (destined for customers), focus in the newly developed Frames program is never lost. Strange... I will have to compare both applications more attentively to see what may be going on, since you do not have the original bug. Op di 5 jun. 2018 12:04 schreef Florian Groothuis <magic@...>: I tried to simulate this but I'm using XPA3.2 and the focus on the table is never lost. |
||||
|
|
