I want to call Prism.highlightElement or Prism.highlightAll after doing some other javascript processing on my code blocks. I can somewhat control the moment that Prism processes by where I place the <script src="prism.js"></script> but I don't see a way to disable automated processing.
Super kludgy answer:
Even though I asked for the development, not minified, version of prism.js when I download, what I got is kind of minified. Anyway, I found this bit of code:
var a=document.getElementsByTagName("script")
and changed it to this:
var a=document.getElementsByTagName("scriptxx")
So, nothing gets highlighted now, until I explicitly call Prism.highlightAll().
Related
What can cause the start render to be delayed even after the load event has fired?
Look at this webpagetest result
This is most probably a bug. For the moment, the iPhone instance on WebPageTest is quite recent and the author is still improving it:
The iOS support is just becoming stable though it's still under VERY active development so don't be surprised if there are a few rough edges (and a lot more limitations than the android testing).
- Patrick Meenan, 09-09-2015
The android tests are much more reliable.
If you check the page you tested without javascript (F1 > Disable Javascript in Chrome DevTools), you can see that most images are lazy-loaded, which mean they are loaded via a JS script checking if the images are in the viewport. As you can see, without JS the load time line is well after all assets loaded.
Also for other assets, like JS, you can add an async or defer attribute to de-synchronize your scripts loads.
Finally, some scripts can be even deliberately loaded after the load event using an attachment on the window load event to write <script> tags in the body when it's triggered as loadJS do for example.
You should read that by the way to better understand how rendering and events timing work.
Last days I search for best and shortest way to convert html files to pdf. Since I create my html files with C program and see them through gtkwebkit which uses cairo it should be some efficient and direct way to convert content of showed page to html with C (I think).
But can't find any example or direction to go on the net.
Until now, among different virtual printers, I find only commandline tools which are maded in perl or which depends on qt what is not wanted.
Please for any suggestion, example or advice to get this functionality from gtkwebkit and if not, maybe something with some tiny C library.
As far as I can tell from reading the documentation (haven't tried it out myself):
Get the main frame with webkit_web_view_get_main_frame().
Create a GtkPrintOperation with gtk_print_operation_new().
Set the export-file property on your print operation to be the name of the PDF you want to export to.
Print the frame with webkit_web_frame_print_full(). Make sure to pass GTK_PRINT_OPERATION_ACTION_EXPORT as the 'action' parameter.
I once wrote some code, to accomplish that without opening a window. But then I ran into a problem with using that code from multiple threads (in a webserver e.g.). I made some research and I figured out that gtk itself is single threaded. So I made my code thread safe, by queuing the print operations to the main thread. Anyway, if it helps, check it out... https://github.com/gnudles/wkgtkprinter
I eventually couldn't get any further with my program due to the various shortcomings of VB.NET (bad audio support, no reading events in the middle of execution, very weak keyboard input, etc). So I tried SDL.NET 6.1.
Despite its terrible documentation, I was able to fix my code to use it and I love it!
But there's a problem. I don't know how to set up my application settings for it. The Startup Object definitely should be a class (the examples always are in classes, never modules), but a startup class specifically has to be a form! This is bad because SDL makes its own window via SetVideoMode; you don't need a form. So when the form constructor New() finishes, a useless form is created and you have two windows.
I tried placing a call to the game engine loop within New() so that the game starts up without New() ever finishing. The game runs normally, and this solves the "second window" problem... but it can't be closed! X button does nothing, calls to Events.QuitApplication or Me.Close are blatantly ignored, etc.
I'm stumped. It seems I need to set a non-form class as the startup object, but it won't let me.
Oh, by the way, it seems that there are two things called "SDL NET". To clarify, I'm using this one, which exists in the SdlDotNet namespace.
Oh, I forgot to mention, I also noticed that a lot of the examples have a line that says "[STAThread]". Is this is important?
EDIT:
I've already received and accepted an answer for my question, but I want to tell other people what the problem is with exiting/closing the app, even though that wasn't my question:
While SDL.NET allows you to receive input and run other events without having to stop running logic, the application still cannot quit while logic is being run. So I find the best way to tell your SDL.NET application to Quit in the middle of running logic is to use the following TWO lines:
SdlDotNet.Core.Events.QuitApplication
End
Place these in the handler for the SdlDotNet.Core.Events.Quit event, as well as anywhere else you want your program to quit.
The Startup Object definitely should be a class (the examples always are in classes, never modules)
Here's your mistake. There's no real difference between a class and a VB module from CLR perspective. So just make it a module with Main and go on. There is no need for a class. I suspect you're looking at C# examples, which use classes - but that's because there is no such thing as a module in C#.
[STAThread] probably won't make any difference for SDL. It is important for UI applications (both WinForms and WPF require it), but I don't think that SDL does any COM calls, so it shouldn't care whether your thread is STA or not. It's just something that Visual Studio puts on Main in new projects by default.
If anyone knows TinyMCE well, do you know if it has built-in support for periodically calling its triggerSave function?
(This function copies it's content to its "parent" textarea. I want to observe said textarea for changes so I can implement autosave.)
Thanks
Don't try autosave, trust me on this one. triggerSave is buggy and when it fails it fails silently so you think that your content got posted, but in reality it didn't. After it fails once it will no longer work for the rest of the session, as in until the page is manually reloaded and tinymce does another full init().
Just got bit by this one badly, again. Never again trust triggerSave.
You could easily do this yourself by using JavaScript's setTimeout() function.
See http://www.w3schools.com/js/js_timing.asp.
I've encountered what seems like a chicken & egg problem, and have what I think is a logical solution. However, it occurred to me that others must have encountered something similar, so I figured I'd float it out there for the masses.
The situation is that I want to use dojo's addOnLoad function to queue up a number of callbacks which should be executed after the DOM has completed rendering on the client side. So what I'm doing is as follows:
<html>
<head>
<script type="text/javascript" src="dojo.xd.js"></script>
...
</head>
<body>
...
<script type="text/javascript">
dojo.addOnLoad( ... );
dojo.addOnLoad( ... );
...
</script>
</body>
</html>
Now, the issue is that I seem to be calling dojo.addOnLoad before the entire Dojo library has been downloaded the browser. This makes sense in a way, because the inline SCRIPT contents should be executed before the entire DOM is loaded (and the normal body onload callback is triggered).
My question is this - is my approach sound, or would it make more sense to register a normal/standard body onload JavaScript callback to call a function, which does the same work that each of the dojo.addOnLoads is doing in the SCRIPT block. Of course, this begs the question, why would you ever then use dojo.addOnLoad if you're not guaranteed that the Dojo library will be loaded prior to using the library?
Hopefully this situation makes sense to someone other than me. Seems like someone else may have encountered this situation.
Thoughts?
Best Regards,
Adam Rice
You're doing it correctly. External Javascript files are loaded and executed synchronously in order, so by the time it reaches your dojo.addOnLoad( ... ); Dojo has loaded. Use dojo.addOnLoad instead of window.onload for two reasons:
it fires earlier, because it utilizes DOMContentLoaded
it handles asynchronous loading of dojo.require by postponing the execution until all required scripts have been read
Explained in DojoCampus as (dojo.addOnLoad):
dojo.addOnLoad is a fundamental aspect
of using Dojo. Passing addOnLoad a
function will register the function to
run when the Dom is ready. This
differs slightly from document.ready
and body.onload in that addOnLoad
waits until all dojo.require() (and
their recursive dependencies) have
loaded before firing.
This might have nothing to do with your problem, but ive just had a case where I had the same symptoms. For me everything worked fine for Firefox, Chrome etc, but not IE8.
I was getting what looked like dojo not being loaded, an error in IE8 saying that dojo was undefined (but not all the time) and i could strip everything down to just style sheets and importing dojo and still get the error.
I was running a local google app engine development server. This looks to be based on pythons SimpleHTTPServer which in turn uses SocketServer.BaseServer. This has BaseServer.request_queue_size which defaults to 5 - i couldn't find anything in app engine which overrode this value so i guess the development google app engine server has an upper limit of 5 connections.
Using regedit and going to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
“MaxConnectionsPerServer”=dword:00000010
“MaxConnectionsPer1_0Server”=dword:0000010
This shows that IE was going to try and open up to 10 simultaneous connections. I edited these two keys and made them 2 and restarted the computer, the problem went away.