February 13, 200521 yr >Is it the printscreen by>itself ? Is it the processing to jpg format ? Or is it the>save to the harddisk ?I guess it's the processing to jpg, and in my case the upload over the internet to my ISP... Saving <=100K to a harddisk should not be a problem, although if you want to do that twice a second ??I was using the SnagIt program, here's a link:http://www.softwarecasa.com/pprod/212401dd...urce=gooc41g01cNicowww.nicokaan.nl
February 13, 200521 yr No save to harddisk.Just get the data from the prtscrn action into the software and compare it to the previous.
February 13, 200521 yr >Just get the data from the prtscrn action into the software>and compare it to the previous.Is there another way to get the data from the SnagIt type program into your own decoding software then via a file on harddisk?a file on a RAM-disk?...Nicowww.nicokaan.nl
February 14, 200521 yr NicoIf all else fails and the SDK is not available I'm still toying with the idea of photo detectors (which sense a light change and output directly to an LED) positioned over each annunciator on a screen displaying the panel. It sounds crude but avoids any software load (FPS hit), and should be very reliable and instantaneous in response. I haven't done any experimentation yet in the hope we can overcome this output problem with ideas suggested on this topic.I plan to trial it at some stage and will report.
February 14, 200521 yr I think photo detectors will be difficult. I tried that concept a few years ago to test power supply indicator lights (actually they were LED's... red and green) and it was VERY difficult. Intensity of the light source and "view" angle of the decector were a problem. Most detectors, of that time, worked over a specific wavelength (mostly toward the infrared end of the spectrum). Once outside the bandwidth of the "color", you needed a lot of gain in the circuit to tell the difference between different colors. That of course screwed up everything that was within the bandwidth. While I've never "played" with them, maybe CCD's would be a better option.Gus
February 14, 200521 yr Or you could buy a slave or a monkey and train them to flick a switch when something changes on the display they watch :(I'll check into capturing prtscrn data as soon as i find time.
February 14, 200521 yr there are colorsensors available, altough a bit pricy...There was a big sale on inkoopacties.net a while ago, but they were still about 5
February 15, 200521 yr I got as far as "Base64".I figured a way to import an image from the clipboard to a picture box in VB.Net.Now I need to figure out how to compare one image to the previous one and find the co
February 15, 200521 yr At some point you might wonder if it is easier to build something like PMSystems from scratch - a tool which you can use to construct aircraft systems logic - instead of trying to interface one panel? Since then you wouldnt need those panels on a hidden monitor either.And remember to keep the research costs below $200 :)//Tuomas
February 15, 200521 yr It is indeed easiest to build own logic from scrats ...Dim YouIsAGoodProgrammer As BooleanIf YouIsAGoodProgrammer = True Then Msg("This is easy")End If... you get my point, right.Today I got a bit furder. I got as far as importing the image from the clipboard after a printscreen has been taken and get the R, G and B value of a pixel I chose.Only problem I still got is that the amount of RAM used by my software is increasing rapidly :( And I don't understand why.
February 15, 200521 yr Well, I do understand why...Visual... Basic...Seriously, I wouldn't use VB to write something like this.Use C/C++ or similar, or even better, ASM (Respect if you can do that)
February 15, 200521 yr Than it will have to be someone else taking up this task because all I know is VB.Net and I am not willing to learn C or C++ just for this software. I won't be using it myself. I am just trying to figure it out as a service to the comunity cuz this would put all doors wide open!
February 15, 200521 yr >Seriously, I wouldn't use VB to write something like this.>Use C/C++ or similar, or even better, ASM (Respect if you can>do that)I could not agree more!Here is the C-example:// Test.c by Nico W Kaan feb 2005 #include BOOL YouAreAGoodProgrammer;void test() { if (YouAreAGoodProgrammer) { MessageBox (NULL, "This is easy", NULL, 0) ; }}int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow){ mainWindow = hPrevInstance; test(); return 0;}Cheers!!Nicowww.nicokaan.nl
February 15, 200521 yr >Well, I do understand why...>Visual... Basic...>Seriously, I wouldn't use VB to write something like this.>Use C/C++ or similar, or even better, ASM (Respect if you can>do that)Wouldn't want to start a which-is-better-language flame war, by saying that vb.net uses exactly the same resources as C++ when using the .net platform.So if memory requirements start growing it is down to bad programming (no offence!) or it is needed. For example, if you take the picture from the clipboard and proccess it to 3 R-G-B ones then you end up working with 4 pictures, while by using the windows API one could work on the image as it is on the clipboard.
February 15, 200521 yr "No flame war" is a good idea, so just face the facts:VB.net is written in C (or was it c++ :s not sure) so it can't be as fastAltough good programming can indeed make it faster, it will never be as fast as genuine and good written c++Do not misunderstand me, I also code in VB sometimes, as it's easy and fast (to write), but I preffer c++ for the real nasty stuffMy suggestion is to dig up the vars of FS (or the prog you're aiming at) from your RAMA little research on google will learn you a lot
Create an account or sign in to comment