I have a rather complex web page structure containing a Silverlight control. The control loads and functions fine. However, sometimes the control seems to auto-reload itself. I'm not sure how, or why - and I'm fairly sure there's no external code in the web page that's causing it.
Basically, the way I noticed this is that the control contains some cached data. When it's created, the data is passed from JavaScript to the Silverlight control, which is then cached. The data is then deleted from the JavaScript side. Almost randomly, the Silverlight control throws an error saying there is no cached data. I found that this is because the control is re-loaded somehow - though not by JavaScript as the relevant area within JavaScript where the SL control is created is never hit a second time. But the Application_Startup event handler within the SL control is hit a second time.
Unfortunately, I cannot post the code as it is commercial and I have not yet managed to recreate this issue in a test project. I will post code if/when I do.
If that makes any sense, does anyone have any thoughts or suggestions on the matter?
You can see plugins auto reload when specific DOM elements change. Are you manipulating the DOM somehow?
Here's an example of it happening in Flash, though I've ran into the same issue with Silverlight. This is more of a Browser issue and not specific to Silverlight or Flash.
Stop reloading flash file when using show and hide methods
Related
I have a problem with javascript generated web page. I have a web page on the internet that is generated by javascript. I am working on changing a web page using wpf web browser control. I have to make some changes to the web page by inserting jquery, and changing css and hiding some elements.
Here is the issue.
Application works ok most of the time, but sometimes, for reasons unknown, it does not change the css or hides the elements. I presume that it has something to do with the javascript that actually generates the page. My code is executed, but no changes are made, so I presume that the script cannot find the elements in the page because they do not exist in the page, at the time of the execution of my scripts. This is just an assumption.
I need help resolving this issue. I have tried delaying the execution of my scripts for n seconds, waiting for body.ready, document.ready and window.ready, but nothing helped. Also, I use wpf web browsers LoadCompleted event, but... From time to time, the script simply makes no effect on the page. Did somebody have this issue, does anyone have any idea how to solve it?
Thank you very much in advance...
When building single page apps, always use a framework like Backbone or Sammy.js together with Mustachejs (or Hogan.js) for templating.
Since we don't have any code to look at, if you're using jQuery, I suggest you check out .live() and .on() for attaching event handlers to elements you plan on loading into a div (making them clickable) etc.
I have a page which contains user controls with Telerik Charts (grids also, but they work fine). From this page, the user can click on a button to be redirected to a "Printer-Friendly Version" type page, which opens a new window via javascript and goes through a slightly different view (for formatting and stuff), but the telerik code is all the same.
The problem is, my Chart displays just fine in the original window, but the new window displays basically an empty chart with no data. This bug is only present in IE, and only applies to Charts. Grids work fine, for whatever reason. I'm thinking this is due to differences in script caching between browsers -- correct me if I'm wrong, I'm semi-new to client-directed web development.
Anyway I read somewhere that Telerik has issues with loading data and/or js files when loaded via ajax, so maybe that's the problem? If so, how could I get around this? And if not, any ideas on what could be causing this issue? It's causing me a great deal of frustration, since a print preview page seems like it should be the easiest of jobs.
Edit:
The charts are being rendered as html (if somebody can explain how to render them as images, that would be awesome). And dev tools shows basically the same thing between chrome and IE. Whenever my web service goes back up ill WinMerge them and look for any peculiarities/differences between them. In the mean time, though, the "render as an image" concept sounds promising. That way I could just save the image from the first page, and insert it right into the print preview page, right?. And since it's a print-preview page, it's not going to need to be interactive or anything, so that'd work out nicely.
Another (important) Edit:
These are probably the culprit...
And here is a little more detail on that:
And here is a side-by-side of it working(in chrome) and not working (in IE):
Have you considered using a print-specific stylesheet instead, e.g.
<link rel="stylesheet" type="text/css" media="print" href="print.css" />
In which you specify the styling to apply when printing.
That way, you avoid reloading the page (duplicate database hits, etc.) and don't need to delve into the AJAX of Telerik's controls.
EDIT:
Regarding using an image rather than HTML, first make sure you won't lose any features/detail, then check out the .Save() method of the RadChart control. You could either save it to a memory stream, or if you want to re-use the image save it to a directory on the webserver and clean it up periodically. That way, you can just point your print version to the image and not re-generate it.
This Telerik forum post may be of use.
Just wondering if there is a way to access the recent pages visited in the WPF WebBrowser. It obviously keeps track of the pages, as evidenced by by the Go[Forward/Back] functions. I am planning on making a database to keep track of it, but I didn't want to do extra work if it was pointless to do so. I am guessing those details are purposely hidden to the user.
No I don't think that's possible, there's just the GoForward/GoBack methods to use. The history in the WebBrowser control seems to be tied into Windows (so opening a URL in your WebBrowser adds it to IE history and vice-versa), I guess that's why they've restricted access to it. Writing your own way to keep track may be a bit of duplicated effort, but it's the way to go in this case.
Navigation control is handled by the NavigationService class and it appears that there is only a "Next" and "Previous" functionality supported.
I don't see any direct way of getting access to the whole chain of visited pages.
I am struggling with finding clear answers to dynamically creating the same page over and over. The questions and samples I have found seem to be all over the board on this topic. I have studied the life cycle and still seem to not have a clear answer as to where code should go.
I have a master page and a content page. All the content in the content area needs to be dynamically created (text boxes, ddl's, page tabs, buttons/onclick etc.).
After a user fills in data and clicks a submit button, I need to read the values off the form and rebuild the page completely again (not add/remove controls to current content).
My question is then.
Where do I put my code to build the page?
Will this area allow me to use IsPostBack so I can rebuild content with Request.Form values?
Will my buttons _Click events work?
Are there any working samples out there you could direct me to?
Thank you very much for the feedback...
I don't know all the answers to your questions, but I hope this may get you started. When dynamically generating the UI through code, this happens in Init. Controls dynamically loaded on Init is key because between init and load, on postback, viewstate is loaded for these controls.
This means you need, on every postback, recreate the page as is to match the previous control tree, then deconstruct it after init and recreate the new UI, if something is supposed to change UI wise. This is because it validates the tree structure to determine its the same UI. Now, if you don't need viewstate, this may not be as much of an issue. I haven't verified this without viewstate to see if it behaves different.
It depends how dynamic you need it, whether you need viewstate (is a big factor).
HTH.
Try creating the controls in the page's PreInit method. "IsPostBack" should work and the click event handlers should work as well.
What you need is a web user control, see ASP.NET User Controls
Brian's advices are good and you should follow them.
This might not really answer your question but still I add it as an advice. I'm professionally creating ASP.net web applications at quite a large scale and from my experience I can say that too much "dynamics" is usually bad and should be avoided because it just introduces complexity. Normally you might want to expose UI parts into ASP.net UserControls or if you want to make them even more reusable (if that's a factor) then into ASP.net Server controls. Then you replace different of them dynamically rather than creating everything from scratch.
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.