3 posts in this topic
Dear AutoIT Community.
I am currently working on a program that will display lots of images in a scroll down GUI.
I create the GUI based on the number of images, which works fine.
But all images I place using GuiCtrlCreatePic above a threshold of around 32000 pixels (cant say exactly) are placed at negative locations and finally will reach 0 again
and will then populate on top of the images placed there before.
For $i = 1 To $Images ; Get picture dimensions $hImage = _GDIPlus_ImageLoadFromFile($ImgRep & $Images[$i]) $iX = _GDIPlus_ImageGetWidth($hImage) $iY = _GDIPlus_ImageGetHeight($hImage) _GDIPlus_ImageDispose($hImage) ; Resize & place images in GUI $Pic[$i] = GUICtrlCreatePic($ImgRep & $Images[$i], $Spacer, Round($yPos, 0), $MaxImgWidth, $MaxImgWidth * ($iY / $iX)) $yPos = $yPos + $MaxImgWidth * ($iY / $iX) + $Spacer $log = $log & "|" & $yPos $currentlut = $Images Next I have found a limit at 32767 pixels for some GUI elements when googling around.
Can someone tell me how to circumvent that?
I have a working program currently driven largely through menu selections. I would like to add a toolbar where most of the tollbar button actions are basically the same as menu items, but quicker to access. I have been wading around in toolbar examples, MSDN pages etc, it's clearly going to be a bit of a slog to get everything right, including tooltips etc. I thought I would start with something simple to prove the principle.
Using bits from the help file examples I have a small program that successfully displays a toolbar. However, what seemed like the most elegant way to deal with the button commands does not seem to work. My understanding was that a toolbar button fires a WM_COMMAND message, with the command Id set by the second parameter in the call to
_GUICtrlToolbar_AddButton ( $hWnd, $iID, $iImage)
so I though it would be a good idea to set this Id to the same value as my menu item Id; then it would run the same task which is what I wanted. This did not work. I am using message loop mode and would like to stick with this because some of my scripts run hardware at the same time as the gui; it is easier if I don't have to worry about code being interrupted with the hardware in an unknown state . So I added a handler for WM_COMMAND, with some cribbed display code to try and see why. The toolbar button defintely fired a WM_COMMAND message and the Id looked the same, so no explanation there.
I guess the issue is with GUIGetMsg() which may be constructed to ignore all but a limited number of control handles, i.e. those made with the GuiCtrlCreate... commands; this is speculation.
I would dearly love to find a tidy way to get around this. Having some controls handled in the message loop and some in a WM_COMMAND handler, performing the same task, feels ugly. I would be very grateful for further insight from someone experienced with handling a toolbar. Perhaps I should be trying to fire the menu item. I have attached a code snippet to try and illustrate the issue.
If possible please add or edit the comments to explain how this works.
;includes functions from other things
Global $win_title ;name of the window
Global $area_x ;
Global $area_y ;
Global $area_w ;
Global $area_h ;
Global $cursor ;
Global $rect_file ;
Global $hbmpscreen ;
Global $i= 1043 ;moves the rect
Global $ii= 378 ;moves the rect
Global $x=1044 ;inner rect offset
Global $y=501 ;inner rect offset
Global $hbmprect ;image inside rect
Global $hscreen ;image whole screen
;display hotkeys on screen
ToolTip("Press F1 to scan | Press ESC to Exit",0,0)
;infinite loop to keep prog running
;~ reads your screen area:
;~ converts screen captured into bmp
;~ . Loads converted bmp to be read
;~ compares the bmp of your scanned screen to the actual screen that is being displayed
$hscreen = _ScreenCapture_CaptureWnd("", WinGetHandle($win_title), $area_x, $area_y, $area_x + $area_w, $area_y + $area_h, $cursor)
;converts screen into bmp
;loads converted screen
;compares savedBMP to current screen
;If( below code ) = ( below code ) Then
If _GDIPlus_BitmapGetPixel($hbmpscreen, ($i + $x) - $area_x, ($ii + $y) - $area_y) = _GDIPlus_BitmapGetPixel($hbmprect, $x, $y) Then
;display message box titled found with a message of found
;if above is not correct then
I'm using UseTraySetIcon("shell32.dll", xx) to set my tray icon to a specific icon while running, is there a way I can specify this icon when I compile my script into an exe so my exe icon is the same?
I am busy with building a solution for change monitoring of VOIP call program and to be properly automated means among others need for some limited OCR functionality. Current works of others are way too much overkill for this case what makes the need to build it myself. But to do it properly I significantly have to increase my knowledge about digital graphics management.
For now I already have discovered here and there some mind blowing Autoit miracles what can be achieved with Windows own possibilities to manipulate that what is output to the monitor. And as far I can judge there are 2 options to process graphics without use of any external libraries like ImageMagick, FreeImage and so on. These are:
WinAPI GDIPlus It is for me quite obvious to have various holes in general understanding of graphics and it is once more very clear what advantages gives consistent general study in 1 or another official institutions like University. Cause there you are introduced into certain domain of knowledge in a way which usually has been perfected over long period of time. So you are not overloaded by stuff which requires a certain amount of information to be initially clear for you. For example, before starting to solve physics you first learn to read, count and so on and then move to subjects like physics.
Though in my case opportunity to study in such educational system I had only for 8 years, from my 7th to 15th year of age in the country that was falling apart now Ukraine but used to be USSR, was all what it was. After have immigrated to Netherlands possibilities to study further haven't occur. And this therefor causes often various implications when going deep in that or another field of practical knowledge acquiring for any needed physical result, like programming to perform enormous amount of tasks. In this particular case automating VOIP call program.
Anyway, right now I think the best direction to move is to concentrate on as basic as possible image management and if someone would maybe explain in general what is a pixel will definitely help. Particularly I am very curious about how to do picture manipulations in Autoit. Especially would help a lot to produce eventually following functions:
createImage($imageFileName, $width, $height, $color) readImagePixel($imageFileName, $x, $y) writeImagePixel($imageFileName, $x, $y) I do not know exactly how image is handled in computer but preferably above mentioned functions should deal with so far possible origin of graphics creation on computer. But nevertheless I definitely would love to hear any proposition for solution.
The problem with explaining screenshots:
VOIPConnect full Window Part of Window with control to monitor for changes Exact location of area where actual changes occur and have to be processed It comes down to a rectangle of approximately 51 pixel wide and 7 pixel high. In fact if I get to learn as far as to be able exactly read, write and compare 2 images consistently across different computers I could narrow down then even further the area to watch as little as a square of 2-5 pixels wide.
To finish here is last detail about particularly no need for ultra fast solution at all. This because it is needed only once when it is first run on a new computer and to have to wait few minutes while it is being set instead of just a few seconds make no sence.
This is it and what I too think to do beside this very particular case is to purify out beautiful generic Autoit functions for core image manipulation by using WinAPI or/and GDIPlus.