Shoutbox

quote:

---

Originally posted by Flippy
The problem is that the editor (or at least the syntax highlighting) thinks that "+ path + ..." is part of the string.
When I run this code it works fine however, so it must be just a bug in the syntax highlighting.

Here's a screenshot to clarify the problem:
[Image: 144hfb.jpg]

---

yes this is a known bug of the scripting window... and its very annoying but patchou is too lazy to fix it =p

quote:

---

Originally posted by NanaFreak

quote:

---

Originally posted by Flippy
The problem is that the editor (or at least the syntax highlighting) thinks that "+ path + ..." is part of the string.
When I run this code it works fine however, so it must be just a bug in the syntax highlighting.

Here's a screenshot to clarify the problem:
[Image: 144hfb.jpg]

---

yes this is a known bug of the scripting window... and its very annoying but patchou is too lazy to fix it =p

---

And that's exactly why I do my coding in an external editor!

Ok, I found Javascript code to find the size of an image, but it doesn't work in jscript

javascript code:

---

var newImg = new Image();
newImg.src = imgSrc;
var height = newImg.height;
var width = newImg.width;

---

But 'Image' isn't recognized... I'm plowing on

That's because JavaScript differs from JScript in some points. In this case, the Image object is available in JavaScript but not in JScript.

Unfortunately, you'll have to dive into advanced code to get the size of the image. Graphical stuff is done by the GDI and GDI+ libraries from Windows, and those are not the easiest to work with.

As tester and interface designer of the upcoming Screenshot Sender 5, I know that it has a nice script class to work with GDI+ functions. I'll ask matty, the creator of SS5, if it's okay for him if you get this part of the code. I'll let you know when I got a reply.

Wow, so many thanks for that!

I had it working a minute ago, and wanted to show a screenshot, but now I changed something in the latex document ('preamble') and it's now printing page numbers too, making the image very large for no reason lol
Just gotta find out how to get rid of the page number and I can show a screenshot...

Ok got it

Screenshots:
Inline equation (meaning, equations and text simultaneously):


Displaystyle equation (meaning, only one equation, no text):

Now that's really cool! Are you planning to publicly release that?

Sure, once it's ready

It's far from ready at the moment. One thing that is still bugging me is that it doesn't work when you keep the little window open. I'm assuming that the png file is in use that way, and the dvipng command does not work properly. In each case, the new png image is not created, so you have to close the window before you can receive a new file...

I'm still looking for a way to solve this. One solution I thought of would be to delete the PNG as soon as it is loaded into the ImageElement. Of course, that only works if the ImageElement has it loaded into memory, or is still using it. If it's still using it I won't be able to delete it...

Another solution, which I already tried, was to delete the PNG before creating the new image. However, I keep getting an "access denied" error whenever I try that (even when the window is closed!). I haven't figured out why yet... Perhaps I need to set the wnd object to null or something, maybe it's still in memory, using the png file?


Anyway... Once that works, I want the window to pop up to the side of the chat window (if there is room). I need to find the size and location of the chat window (which I assume can be done with an API call) and then determine where there's room to place the window. If there's no room I'll just display it near the top of the chat window, which would usually be on top of the chat history, so you can still see the most recent messages...


Once's that is done, I actually want to make it a bit more complex, lol. I could have some kind of history where multiple images are stored into the history, and you can browse back. Otherwise, if your chat buddy is typing too fast, and types two equations after each other, you may miss one

Oh well, let's get this basic stuff working first hehe...

Hmm, here is an idea:

• Generate a random number for each created PNG file, e.g. "845217623.png". This will prevent any writing access trouble.
  
• When the PNG is created, create the window and load the image. Store the loaded image's file name in a global object, indexed by the window's handle.
  
• When the window is destroyed, the file name is looked up from the global object and the image is deleted.

I think that'll work. I know it's not the most elegant solution, but I'll leave the challenge for you to play around with this idea.

As for finding out the position of the chat window, have a look at GetWindowRect (user32). Create a RECT memory structure using Interop.Allocate(), make the function fill it and use the data in the RECT structure to figure out where to place your window.

@matty: Okay, it'll work just fine with the time too. I don't know whether you want to delete those created images after closing the window, so I'll leave my comment untouched just in case.

My suggestion is the following:

js code:

---

var oGdip = new Gdip();
    if ( oGdip.Initialize() === true ) {
>>>        oGdip.ConvertImage( 'C:\\myImage.png', 'C:\\myImage'+new Date().getTime()+'.jpg', 'JPG', 75 );<<<
        Debug.Trace( oGdip.GetImageDimensions( 'C:\\myImage.jpg' ) );
        oGdip.Uninitialize();
    } else Debug.Trace ( 'An error occured while initializing Gdi+' );

---

Then you can load the new JPG file and overwrite the PNG. Then you can create as many windows as needed as long as you load the latest image

Well, I got it working by simply closing the window before generating the new PNG file.

If I ever want to try my more advanced idea (multiple images in history) then I probably need to have a look at your suggestions. But for now, this works fine.
I also don't want a separate window for every equation, that would become very unwieldy.


Right now I'm looking at some error trapping in the command line part. If the latex code is invalid for some reason, the compiler does not continue and my conversation window locks up. I am pretty sure I can retrieve some error information from the later compiler though, so it won't be a problem to check for that. The problem is I don't know yet how But I'll get it hehe...