HTML:
var embed1 = document.getElementById('yyqtest');
embed1.testProperty=5;
But, in my plugin: SetProperty(NPIdentifier name, const NPVariant *value);
value always null! Why?
The same code, in firefox is run OK, the *value is 5
My Chrome version is:
16.0.912.63 m
Well, I could speculate, but you've provided absolutely no useful details. I can tell you with a fair amount of certainty that the problem is not due to a new incompatibility in your version of Chrome (unless you installed that from source control directly?) so the problem is most likely somewhere in your code; however, since you haven't posted any of your code other than a bit of javascript there is no way to guess.
Barring that, let me give you a few debugging tips:
First, try using an object tag instead of an embed; I've just had weird issues with object tags.
Second, are you absolutely certain that the SetProperty on your NPObject is even being called? Is the plugin being loaded? How do you know the value is always null? Did you test it afterwords, and is it possible it just hasn't been changed because the function was never called?
What OS are you on? Have you tried attaching a debugger? Have you considered using FireBreath instead of doing it from scratch so that you don't have to worry about knowing all of these details?
If none of that helps I highly recommend you add a lot of detail to your question and try again, because what you have given doesn't give any of the details we'd need to do more than speculate wildly.
Related
I am trying to convert the contents of a UWP RichEditBox to HTML.
For that purpose, I've tried using the RtfPipe library (https://github.com/erdomke/RtfPipe). From the looks of it, this library has a problem on UWP, due to the fact that not all encodings are defined on that target framework. (This is the error you get, if you are interested: Encoding.GetEncoding can't work in UWP app, but the accepted answer seems not to be the best option on all platforms - I haven't even managed to make the suggested fix compile, so it might not be valid anymore)
Now, as a way of avoiding this from happening, I am wondering whether there is a way to force the control to always use one of the UWP-defined UTF-variants for encoding the data when the user types his text.
Because, now, when I type into it, I get things like that:
{\rtf1\fbidis\ansi\ansicpg1253\deff0\nouicompat\deflang1032{
....
\pard\tx720\cf1\f0\fs23\lang1033
...that make the library throw exceptions.
I guess, if I manage to make it not use ASCII code pages, things will be great.
After taking a look at the control properties though, I do not see something I could use. Is there any way to achieve this?
This is the error you get, if you are interested: Encoding.GetEncoding can't work in UWP app
As you described, there is an inner error thrown when using this package with UWP app. System.ArgumentException: 'Windows-1252' is not a supported encoding name, by testing on my side, which is thrown by the code line public static readonly Encoding AnsiEncoding = Encoding.GetEncoding("Windows-1252"); of RtfSpec.cs when UpdateEncoding.
It seems like Windows-1252 may not be supported in UWP from the error details,also see this similar thread. You could use UTF instead as you want, for example, have a change on the library with following then it will work (testing demo here).
public static readonly Encoding AnsiEncoding = Encoding.UTF8;
I haven't even managed to make the suggested fix compile, so it might not be valid anymore
Encoding.RegisterProvider method should be work, but it only support UWP or .NET Framework 4.6, it does't support the Portable Class Library. The RtfPipe library you mentioned is Portable Class Library, so that you cannot use Encoding.RegisterProvider. Encoding.GetEncoding method supports Portable Class Library, details please check the version information of the two classed.
I guess, if I manage to make it not use ASCII code pages
RTF itself uses the ANSI, PC-8, Macintosh, or IBM PC character set to control the representation and formatting of a document, you may not able to change that. Consider to update the library to resolve the issue for UWP.
According to MDN:
Async...indicate that the browser should, if possible, execute the script asynchronously
The definition is really vague. So let me phrase my understanding explicitly and please correct me if I am wrong:
My first question is that When I use the keyword async to load a 3rd party script, the browser will continue to parse the DOM elements after the tag while downloading the script via a different thread. I want to know how browsers actually implemented the asychnoronous.
Is my interpretation correct?
My second question is that When would be a good situation to use async instead of defer? (I understand the differences between them, I just don't know when would be the case to use one instead of the other)
Let's say a script I want to include does not have any dependencies and it is not depend upon by other scripts. Why is it recommend to use async in this case instead of defer other than the difference in execution timing?
Here's what the spec says:
https://www.w3.org/TR/html-markup/script.html#script.attrs.async
async Specifies that the script should be executed asynchronously, as soon as it becomes available.
https://www.w3.org/TR/html-markup/script.html#script.attrs.defer
defer Specifies that script should be executed after the document has been parsed.
Any one know where the function window.document.all is defined? Tried searches but nothing coming up.
Many thanks
Edit: note I am aware that thus deprecated and documentgetelementbyid should be used. still need to know what is executed when this function is run.
It has nothing to do with Google V8. It is a legacy property of the document object. It stores an array of all elements in the document, indexed by ID.
You should use document.getElementById() instead.
If you are asking this question then the source code will probably not be useful to you in the first place. But here you go:
https://github.com/WebKit/webkit/blob/5b7f307f78ff665c0102bd008d2a47b9b2f8e5b5/Source/WebCore/dom/Document.cpp#L4405
I'm using the WkHtmlToXSharp wrapper library in my project to generate PDF file from HTML.
I was using this library a lot of times in different PCs and, suddenly, I came across the following problem:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at WkHtmlToXSharp.WkHtmlToPdfConverter.wkhtmltopdf_convert(IntPtr converter)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert(String inputHtml)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert()
at WkHtmlToXSharp.MultiplexingConverter.b_8()
--- End of inner exception stack trace ---
at Sanford.Threading.DelegateQueue.EndInvoke(IAsyncResult result)
at Sanford.Threading.DelegateQueue.Invoke(Delegate method, Object[] args)
at WkHtmlToXSharp.MultiplexingConverter.Convert()
This seems to be a common problem with this library (I've found some feedback on the web about it - however no fix was provided). BTW, in my case it happens somewhat randomly. I was not experiencing this problem in other dev machines. I wonder if somebody has a fix for it. I also wonder if this is a problem with the wrapper library, if with the WkHtmlToPDF library itself.
Any suggestion? I'm also open to use another converter, as long as it is free and stable and, if possible, without spawning a new process. It must work properly and stable in all Windows versions and do a decent job converting (the HTML to be converted is fixed - contains a few pics and tables and basic CSS).
I would suggest an alternate route: simply use wkhtmltopdf.exe directly, building your own wrapper. They are not very complicated if you have control of the input and then you know exactly how to update it and how the options work. I've never encountered with that problem when using wkhtmltopdf directly (on Win7, Win server 2008 r2, Ubuntu and CentOS). They do spawn process for every conversion though.
For an example, check out the Derp class in another answer of mine regarding wkhtmltopdf. Or try something like the untested code below (your true code will be more complicated, this is just a demo/POC).
var pi = new ProcessStartInfo(#"c:\wkhtmltopdf\wkhtmltopdf.exe");
pi.CreateNoWindow = true;
pi.UseShellExecute = false;
pi.WorkingDirectory = #"c:\wkhtmltopdf\";
pi.Arguments = "http://www.google.com gogl.pdf";
using (var process = Process.Start(pi))
{
process.WaitForExit(99999);
Debug.WriteLine(process.ExitCode);
}
I have a nice fully functioning module (wrtten using tcl/cpp) it works fine.
I want to use ramdebugger to debug scripts using that module
When I enter
load mylib.so
command1_from_lib xx
command2_from lib yy
If (say) command2 returns an error then ramdebugger dies
[paul#paul-es5 ramdebugger7.7.1]$ ./ramdebugger
alloc: invalid block: 0x999c058: 0 0
Aborted
It dies here in libtcl / ResetObjResult
if ((objResultPtr->bytes != NULL)
&& (objResultPtr->bytes != tclEmptyStringRep)) {
ckfree((char *) objResultPtr->bytes);
}
My suspicion is there is confusion over the global tclEmptyStringRep. I think the starkitted(?) ramdebugger has one and the dynamically loaded libtcl has a different one - the bytes pointer should logically be pointing to an empty string but the value there does not match what gdb shows for the global
I am a tcl noob and need any help I can get. Alternatively a suggestion for a different debugger would work
edit: fixed
Use tclStub to defer the link between the extension and the tcl runtime.
This sounds very much like a bug to me, as opposed to a question which this site can answer. You should contact the ramdebugger people to see if they can help.
However, for general Tcl debugging you could also see if the tools produced by ActiveState help; IIRC you can get a free trial to see if they can make any headway. (Myself, I'm of the put-lots-of-printf-calls in school of debugging, so I'm nobody's poster child.)