3 posts in this topic
Please answer me these questions three, ere the other side you see:
Are you running a 64-bit machine with a 64-bit Windows operating system? Can your AutoIt scripts cope with having directive #AutoIt3Wrapper_UseX64=Y, and thus @AutoItX64=True? Are you sick and tired of seeing this error message?
If you (like me) answered "YES" to all three questions, then the _HighMem library may ease your pain (the name commemorates a useful utility from the days when CPUs were still steam-powered). Forget about pathetic boot switches /3GB and /userva; in a full-fledged 64-bit environment, _HighMem can pre-allocate all available physical/virtual RAM you've got (or any smaller size you need), and manage individual allocations therein with four simple functions:
_HighMem_StartUp( $nSize, $sUnit="GB" ) ; parse size of total region to pre-allocate, e.g. (10,"GB") _HighMem_Allocate( $nSize, $sUnit="B" ) ; returns $pOffset (new allocation's base address) _HighMem_Release( $pOffset ) ; existing allocations are identified by their offset (base address) _HighMem_CleanUp() ; close handles, release all pre-allocated memory Of course, existing AutoIt limitations remain in force (e.g., DllstructCreate() is still limited to 2 GB per call), but the maximum of 2-4 GB of virtual memory per Windows process can (under the right circumstances, in the proper environment) be circumvented. However, this is the first beta release, so glitches are likely, and performance may vary. In fact, it may not work at all for you (if you're running 32-bit, for example). And since this involves your own hardware, it's unlikely I would be able to reproduce your issues in my own work environment. Nevertheless, if you find obvious bugs or mistakes in the code, please do post. And if it works for you, that's also good to hear. My own motivation for developing it was to supercharge my matrix computing environment (Eigen4AutoIt), so it can handle matrices of any size that fit in machine RAM.
The attached zip contains the library itself (HighMem.au3) and two test examples. HighMem_Test1 performs a dry run stress test of the allocation management system; it does not actually do any memory I/O. By contrast, HighMem_Test2 pre-allocates a 6 GB space, stores 3 x 2GB structs there, performs some basic I/O, and releases the allocations one by one. Obviously, for this to work you'll need at least that much free RAM to begin with (check with Task Manager -> Performance -> Memory if you're unsure). My own test environment has 16 GB of physical RAM, and runs W10Pro/64.
EDIT: minor edits added to improve user experience (many more status messages if $_HighMem_Verbose=True)
EDIT: from beta version 0.9, HighMem supports shared memory, including mutex negotiation.
Hello all! I have had some issues reading text from different types of windows, occasionally, specifically with controlgettext.
**Before I begin, I know there are better ways to do what I attempt in the example below. That's not the point of this post. The point is my issues with controlgettext.
I am about to cite an example with an application you may be familiar with called SpeedFan (v4.52). My problem is not specific to speedfan, it is simply the most recent and easily reproducible example I can think of.
So, the goal of the script below is to get a string of text containing the current fan RPMs from the highlighted control in the screenshot below (see "speedfan_control_details.png").
Now, here's a simple script for grabbing the window handle and reading the text from that control:
$wintitle = "SpeedFan 4.52" $controlID = "197934" ;will be reformatted as "[ID:######]" $hwnd = wingethandle($wintitle) if @error<>0 then msgbox(0, "WinGetHandle", "FAILURE. @error="&@error) Exit EndIf $text = ControlGetText($hwnd, "", "[ID:"&$controlID&"]") if @error=1 then msgbox(0, "ControlGetText", "FAILURE. @error="&@error) ;failure returns "" and @error=1 Exit EndIf msgbox (0, "ControlGetText", "SUCCESS. @error="&@error &@CRLF& "$text="&$text) ;success returns string and @error=0 You'll see that the ControlGetText operation runs without error, however it does not capture any text from the control. If you explore the other controls in this one window, you'll find mixed results across the board. Neither the temps nor voltages can be read, while the log field and some other elements can be read. Even when you read the text from the whole window, those elements are not included in the visible nor hidden texts.
I have run into this issue many times in the past- inconsistencies in the ability of autoit to interact with certain controls. What is it which makes this text different than any other readable texts? Is there an alternate method of reading the text in the window/control which could work? Any and all info to help me solve this mystery and satisfy my curiosity would be greatly appreciated.
Thanks -Rob C
PS: Running Autoit v18.104.22.168 on Win7 Ultimate x64
Today I'll give you three functions to manage the list View items
These functions will help you to do some works in your list view items
1. list view Read
To get the selected item text
To checke an item
To see if the item is checked
All of these functions will be illustrated by the following example
You can download the include file from the link below
Now with the example
#include <easy_listView_functions.au3> #include <GUIConstantsEx.au3> #include <GuiListView.au3> #include <MsgBoxConstants.au3> Example() Func Example() Local $idListview GUICreate("ListView Get Item Checked State", 1000, 700) $idListview = GUICtrlCreateListView("", 50, 30, 250, 120, 50) _GUICtrlListView_SetExtendedListViewStyle($idListview, BitOR($LVS_EX_FULLROWSELECT, $LVS_EX_CHECKBOXES)) ; Add items $item1 = GUICtrlCreateListViewItem("item1", $idListview) $item2 = GUICtrlCreateListViewItem("item2", $idListview) _listview_Checke($idListview, "item1") $btn = GUICtrlCreateButton("&read", 100, 150, 50, 50) $btn2 = GUICtrlCreateButton("&if checked", 100, 200, 100, 50) GUISetState(@SW_SHOW) while 1 switch GUIGetMSG() case $GUI_EVENT_CLOSE GUIDelete() exit case $btn $read = _ListView_read($idListView) if $read then msgBox(0, "read listview", $read) else msgBox(0, "read listview", "no text ditected") endIf case $btn2 if _isListviewChecked($idListView, "item1") then msgBox(0, "get", "the item is checked") else msgBox(0, "get", "the item isn't checked") endIf endSwitch wend EndFunc ;==>Example
I have 2 items (a field box and a bypass checkbox). every time the box is checked i need the field to become writable. unchecked is read only displaying some text.
this is as far as i got as I am stuck at making it read/write toggle
#include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <EditConstants.au3> #include <WindowsConstants.au3> $hGUI = GUICreate("Test", 500, 500) Global $hCombo = GUICtrlCreateInput("", 10, 10, 200, 20, BitOR($ES_AUTOHSCROLL,$ES_READONLY)) GUICtrlSetBkColor($hCombo,0xe7e5e5) Global $cbox = GUICtrlCreateCheckbox ("", 40,50,10,20) GUICtrlSetState($cbox, $GUI_Unchecked) GUISetState() Global $sCurrCombo = "" While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit Case $cbox If GUICtrlRead($cbox) <> $sCurrCombo Then $sCurrCombo = GUICtrlRead($cbox) GUICtrlSetStyle ($hCombo, $SS_LEFTNOWORDWRAP) GUICtrlSetBkColor($hCombo,0xFFFFFF) MsgBox(0, "Choice", "PLease enter the text") EndIf EndSwitch WEnd
Hi, I have a problem, my functions do not work with each other. Separately, each works very well. Features that do not work together it's loot() and pos1(). It looks that after spreadsheet function loot() script stops working even though everything is in the While 1-Wend loop. Can someone help me please?