Leaderboard

Last updated 9/10/21 * Image may not represent current product Features Simple Integrated countermeasures against file and memory analysis based decompilers. Add basic types of resources into the interpreter or other types as raw data. Define multiple programs to execute pre and post build. Create and include pe version information. User defined patches that can be implemented globally on the interpreter and compiler or selectively. Handles its own basic macro's as well as environment variables in most fields for easier path finding. Drag and drop configs (script bound or separate) to the input edit box or to the icon to load them. Configuration settings can be copied to the clipboard or saved as config files or Au3 scripts. Settings can now be saved directly to an AutoIt3 script. Subsystem independant, can act as a gui or console tool. And much more. See next post for update information. A3C_97.16b.7z A3C_98_18_b.zip

then just disabling redirection should work as well? DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)

UPDATED - see first post. (v2.9) Added the option of adding an ebook without a price, via a prompt dialog. If a price returned during a Query is a new lowest or highest, a comparison with Last price, is also reported. NOTES - Some ebooks exist that don't currently show a price. This is usually because they are no longer currently available. Hopefully, when they do become available again, it will be for the same ISBN number the program uses, so that the user gets advised of this availability. Previously, you were only told the price difference of the change between last lowest or highest, when the price was a new low or high value. If a big price change occurred, you might not realize it, so this extra check and report has been added.

This specific issue relates to running a .cmd/bat through ComSpec with a 32bit compiled .EXE on 64bit OS. In this case, Windows will use the cmd.exe in Syswow. @OP try compile your AutoIT.exe in x64 architecture if you are using Windows x64.

Original answer from this post by binhnx, you should have a look at it if you need more information (Also to know the cons of using the following solution) . This post is made to make life easier for people who have been suffering from this problem Here is your answer: #include-once ; -- Created with ISN Form Studio 2 for ISN AutoIt Studio -- ; #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #Include <GuiButton.au3> Global $test_gui = GUICreate("test",300,300,-1,-1,-1,-1) GUISetBkColor(0xFFFFFF,$test_gui) GUISetState() ; This is the faulty statement: Global $test_child_gui = GUICreate("test child", 150, 150, 0, 0, $WS_POPUP, $WS_EX_MDICHILD, $test_gui) Global $test_child_gui = GUICreate("test child", 150, 150, 0, 0, BitOr($WS_CHILD, $WS_VISIBLE, $WS_CLIPCHILDREN, $WS_CLIPSIBLINGS), -1, $test_gui) ; You should change the faulty statement to the above correct statement to avoid the "Aero Window Apperence Delay" effect.... GUISetBkColor(0xFF0000, $test_child_gui) GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd Before: (click images to animate them) After: TD

Some characters are different in titlecase and uppercase. For instance slavic languages recognize 3 different cases for some digraphs, each of them having their own Unicode codepoints: lowercase, uppercase and all-caps. Note that in the following 4 lines each line displays only 3 letters: DZ is not DZ (the letter D followed by the letter Z): you can place the mouse cursor in the middle of DZ but not in DZ. dz Dz DZ dž Dž DŽ lj Lj LJ nj Nj NJ This is contrary to ligatures where capitalization of the two letters in the glyph always have the same case, for instance Dutch letter ij IJ

@LarsJ: You can also read this thread: Basically, yes, you can create a far more advanced forms with AutoIt, with a condition, you know what you're doing. The OP overuse the child window. With his problem, he should really using one form. But he not. So he totally mess with his resize code. (Yes it my fucking bad, the 2 tab controls make him cannot use only 1 form) Look at his GUI hierarchy: - MainForm ($hGui) - Toolbar - Nested child 1 ($hGui2) (using $WS_EX_MDICHILD,but then reposition manually by intercepting WM_SIZE) - Tab Control1 (This contain 2 tab items) - TreeView1 (contained in 1st tab item) - TreeView2 (contained in 2nd tab item) - Nested child 1.1 ($hGuiInner1) (again, a $WS_POPUP with $WS_EX_MDICHILD and manually position during resize). This is contained in the first item of the tab below tab - Nested tab, with 5 tab items - Nested child 1.2 ($hGuiInner2) (again, a $WS_POPUP with $WS_EX_MDICHILD and manually position during resize). This is positioned in the second item of the TabControl1 - Nested tab, with 2 items So what's going wrong? AutoIt intercept all its GUI message. Guess? When processing WM_SIZE, the OP resize all 3 Gui!!! Then? Let's look - First, main form, $hGUI is resized by user. The system send a WM_SIZE indicate that the window has been resized. - In response to it, the OP resize its direct child, $hGui2 and 2 nested: $hGuiInner1 and hGuiInner2 - $hGui2 resize make the system send another WM_SIZE, and he continue to resize $hGui2 here. It bad. - Its terrible but not disaster, he also resize 2 most nested child: $hGuiInner1 and $hGuiInner2 in his message handler. So bulks of WM_SIZE sent recursive here. Assume that the system code was fast enough or/and he's too lucky so he doesn't see the problems. - The disaster come in when he switch from system-handled-WM_NOTIFY to his own WM_NOTIFY handler. Each resize, multiple WM_NOTIFY is sent. So bulks of (unnecessary) resize * multiples of WM_NOTIFY = disaster. @To the OP: - Edit - : I re-read the tab control problem. So 1 Gui for all is not suitable here. So sorry! Just modify your WM_SIZE handler like this: Func WM_SIZE($hWndGUI, $MsgID, $wParam, $lParam) if ($hWndGUI = $hGui) Then _WinAPI_SetWindowPos($hgui1, 0, 0, 0, _WinAPI_LoWord($lParam)-$aOffsets_1[0]+16, _WinAPI_HiWord($lParam)-$aOffsets_1[1]+38,BitOR($SWP_NOMOVE, $SWP_NOZORDER)) ElseIf ($hWndGUI = $hgui1) Then _WinAPI_SetWindowPos($hGuiInner1, 0, 0, 0, _WinAPI_LoWord($lParam)-$aOffsets_inner1[0]+16, _WinAPI_HiWord($lParam)-$aOffsets_inner1[1]+38,BitOR($SWP_NOMOVE, $SWP_NOZORDER)) _WinAPI_SetWindowPos($hGuiInner2, 0, 0, 0, _WinAPI_LoWord($lParam)-$aOffsets_inner2[0]+16, _WinAPI_HiWord($lParam)-$aOffsets_inner2[1]+38,BitOR($SWP_NOMOVE, $SWP_NOZORDER)) EndIf Return $GUI_RUNDEFMSG EndFunc ;==> WM_SIZE And you will feel much better. PS: And also, take a look at the >thread by @TheDCoder, you will find a solution for the appearing order of your child Guis.

SLOVED IT! the problem was in fact windows 8.1 screen scaling. The white rectangle in the first screen shot I posted was showing what my resolution "looks like" After going into control panel>display I checked "let me choose one scaling for all displays" and then selected 100% autoit now displays the correct resolution. yay! Note to developers: please implement a way to detect the right resolution when using screen scaling. thanks for everyone's input. hopefully this will help others too.

I use SQLite not Oracle and SQLite doesn't have the same date dissection functions, but when I try this I get the expected result: select substr(x__insdate, -2) as Month, count() from reghistory group by month order by month; Hence I suspect this would work as well for you: SELECT EXTRACT(MONTH FROM DATABASE.REGHISTORY.X__INSDATE) as Month, COUNT() FROM DATABASE.REGHISTORY GROUP BY Month order by Month;

JohnOne, The problem reveal when you try to express values in decreasing powers of 2, since FP is binary-based. 0.2 = 1/8 + 1/16 + 1/128 + 1/256 + 1/2048 + 1/4096 + 1/32768 + 1/65536 + ... That is: 0.2 = 2-3 + 2-4 + 2-7 + 2-8 + 2-11 + 2-12 + 2-15 + 2-16 + 2-19 + 2-20 + 2-23 + 2-24 ... Hence you can see the binary pattern for this particular value: 0.00110011001100110011......... This pattern is infinite so when stored in a floating-point register or variable, the value is forcibly truncated.

In the decimal system - but in the binary system it is.