PDA

View Full Version : test my screen writer


OdeeanRDeathshead
15-02-2006, 01:09 PM
I have been working on a class to take care of all my input output directly to the screen buffer on a ppc. I think I have got it working but I do not have any vga device to test on. I have normal orientation screens (most ppc) and one landscape (natively I mean) in my ipaq. There is some complication in the addressing of rotated screens. I would like to know if my drawing turnes out ok on other devices.

If you are willing to give mytest app a go, here is the link
http://odeean.veritel.com.au/demo%20buffer%20user/ORD_Screen_Draw.exe

disclaimer:
The program is supposed to let you draw a series of randomly sized and coloured rectangles on the screen. It clips these so they fit into the buffer for the screen. On all of my devices this works perfectly, but during development it caused many hard resets. If there is a bug that you pick up it could cause anything from nothing at all to needing a hard rest.

the program also can save a screen image at an interval of up to 1 minute. I also would like to know if this works on other devices and resoltions properly. Because this is for testing only, the output is marked so it is not much use for anything. This is to stop people from wanting to use this as a screen saver who have not really understood the potential harm a buffer over run could cause.

It should also work in portrait mode with no difference.
18 bit screens are not supported.(this means atom)

levenum
15-02-2006, 03:21 PM
OK, tried it on iPaq 1950 (WM5) – no bugs.
On LOOX 720 (WM 2003SE VGA) – random fill and fragment are quarter screen everything else works fine. No hard resets so far.

OdeeanRDeathshead
15-02-2006, 03:36 PM
Thank you levenum.

I think the fill is wrong because I binary shifted the random numbers to limit their size. Do the random rects seem to get clipped to a common edge thats 1/4, or do they just not go further over time.

I will post another version tomorrow night with adjustments. I am just glad it didn't crash.

The thing that bugs me is that they call the pointer a pointer to the hardware. It can't be because when I try to screen save from my onboard camera it will not save the image, only the icons on screen. I am going to test a plug in camera tomorrow.

vijay555
15-02-2006, 04:01 PM
OdeeanRDeathshead: do you know if they use overlays on the PPC? I've played with a few apps that seem to exhibit odd characteristics when being manipulated externally/screen grabbed etc; I didn't go further, but it seemed a plausible explanation.

V

OdeeanRDeathshead
16-02-2006, 03:26 AM
I cant give a definite answer. I know that the actual camera data MUST be stored somewhere off the buffer because it is simply too big. If the res is greater than 240 by 320 (and it is) then the camera image must go to a holding area for processing down to a preview for the screen. I tried setting my res to lowest and to bitmap but it did not help.

I am no expert in this, I understand the principle of combining two images for performance but I always thought that the pointer we got was to the hardware. Meaning that the pointer addressed some memory that was hard wired into the pixels. This must be incorrect. If it was the real memory that controlled the pixels then there would be no way to not get the image when saving their state. We must get one of a number of buffers that get combined into the real pixel area.

I know that the memory we do get is definately on the ram allong with everything else. I tested writing over the buffer to gradually increasing degrees. After a certain offset I think I wrote over windows because the device locked up and hard reset by itself.

I think that the camera would write to a fixed location on the ram. Given this it would be possible to search manually until finding the correct spot. It would just take a long time, and my code would need to be re-written to display the maximum res of my camera otherwise I would never know when i found it. Doing it this way would be a hack and not useful for the future :cry:

OdeeanRDeathshead
16-02-2006, 05:53 AM
At least I can grab the screen from my plug in camera....
http://odeean.veritel.com.au/demo%20buffer%20user/SavedScreen.jpg


My pretec camera will not install on my ipaq. In fact not only dose it not install, it forces a hard reset. That software (PPC2002_ENG.exe) from pretec is the most dangerous I have ever found. I get some error about filesys then no more :x

At least it works on my toshiba (shown above).


The new version is now in the location linked above. It should draw the rects over more of the screen in vga devices. As I don't have a vga, if it fails I will wait until later this year when I get my exec before fixing for vga.

levenum
16-02-2006, 10:26 AM
Hi OdeeanRDeathshead!

Tried the new version on the LOOX (just to get a short break from tedious project 8) ), it works full screen, but jams the device at random intervals. Fragment works three-four times in a row, but random wont even finish the first time.
Fortunately though after playing with it for 5 times (yes the current project is driving me nuts :shock: ) there was no need to HR the device.
My guess is you exceeded the buffer but not enough to cause permanent damage.

OdeeanRDeathshead
16-02-2006, 11:47 AM
Thanks again for the help. I will not try to get it working on vga any more until I buy one.

I have been experimenting with the memory surrounding the screen buffer in hope of finding the space the camera uses. I have noticed something that must be more than coincidence. I modified my code to display the contents of memory at increasing intervals from the screen buffer. I can read up to 32 blocks (including the visible screen) but then it fails. I do not know why it fails because the distance from the starting point is only bytesperpixel*ydimension*xdimension*31 ie 2*240*320*31=4761600 bytes.


Screen capture is possible when a picture has been takeen. This shot was captured after the camera button was pressed. I could simulate a button push, then grab the screen image.
http://odeean.veritel.com.au/demo%20buffer%20user/capture002.jpg

Whats your project?

levenum
16-02-2006, 02:13 PM
A content program.

Speaking of which, did you ever mess around with RichInk control?
I am trying to implement a simple text search in it. I find the text, select it (those are easy) but I can't scroll the text in to view.
I tried EM_SCROLLCARET and EM_LINEFROMCHAR but they just return 0, and according to MSDN the control does not support any messages that could be used for this purpose.

If you have any ideas they would be greatly appreciated.
Thanks in advance, and good luck with your new device!
(Its fun getting new toys isn't it :) :) :) )

OdeeanRDeathshead
16-02-2006, 03:06 PM
Ok, did you have it NOT in VT_DRAWINGVIEW when you selected the text. And if you cant see it are you sure you selected it. Have you tried using EM_SCROLL or EM_LINESCROLL or even WM_VSCROLL. If they worked you would need to keep track of the position.

I have not used the richink before. The documentation as you said, is lacking scroll messages. Maybe another example of the unfinished api syndrome.


I tried to broadcast a WM_LBUTTONDOWN followed by WM_LBUTTONUP to simulate button taps to my camera. The code works on ppc2002 but on wm2003 it just flickers the button for a split second then dose nothing. Is there some change in how broadcasts work for newer os?

dose anyone know why this code starts notes even though the registry says the value (0x40c3) is for camera?

PostMessage(HWND_BROADCAST, WM_HOTKEY, 0x40c3,NULL);

OdeeanRDeathshead
16-02-2006, 03:36 PM
I figured out the simulated screen taps..

mouse_event(MOUSEEVENTF_LEFTDOWN|MOUSEEVENTF_ABSOL UTE,61439,1638,0,NULL); mouse_event(MOUSEEVENTF_LEFTUP|MOUSEEVENTF_ABSOLUT E,61439,1638,0,NULL);

That hits the ok/X button for 240/320 res screens.

Still need help with the hardware buttons.



<<<<<<edit>>>>>>

Forget the hardware buttons. I have tried sending messages directly using the window handles for various programs with mapped buttons and they just don't respond. I have played with combinations of other parameters and numbers. The only one ever responding is notes.


this works much better, if:
1) you are trying to dump the screen of the xda II mini camera
2) in the camera settings you have it set to preview after taking a shot
3) the code is executed from a thread that dose not have a message loop.
The camera will not start if another program dose not respont to the os.


//this for launching camera
PROCESS_INFORMATION pi;
::CreateProcess(_T("\\windows\\camera.exe"),
NULL,
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
NULL,
&pi);


Sleep(thisObject->waitThislongBeforeSave);

// Send keypresses that mean enter, camera will take shots when return is pressed
keybd_event(VK_RETURN,0,KEYEVENTF_SILENT,0);
keybd_event(VK_RETURN,0,(KEYEVENTF_KEYUP|KEYEVENTF _SILENT),0);

Sleep(5000);

//this is when I dump the screen
thisObject->_SCREEN_SAVE_();

// Send keypresses that mean enter
keybd_event(VK_RETURN,0,KEYEVENTF_SILENT,0);
keybd_event(VK_RETURN,0,(KEYEVENTF_KEYUP|KEYEVENTF _SILENT),0);

Sleep(2000);

//close the camera
mouse_event(MOUSEEVENTF_LEFTDOWN|MOUSEEVENTF_ABSOL UTE,61439,1638,0,NULL);
mouse_event(MOUSEEVENTF_LEFTUP|MOUSEEVENTF_ABSOLUT E,61439,1638,0,NULL);

I gave generous sleeps to give the camera time to do its thing.