Leaderboard

Hi Guys, So with me working in my Virtual Machines in full screen, I often have my Host OS playing music. Now the issue I had was trying to control the Host OS without having to minimise the Guest OS. So I thought of this small program. I call it the Volume Control. It resides in the bottom right hand corner of your screen just above the system clock. I'm still working on getting the volume buttons to increase/decrease when you hold down the button. Currently, you will need to tap on the volume buttons numerous times to decrease/increase the volume. Any other improvements let me know. The source code, icon and compiled program are already in the zip. Volume Controlv1.zip Screenshot.bmp

Maybe you stored the dates as strings and by using copy & paste Excel interpreted them as dates? Nevermind: Glad the problem could be solved!

Noob can read the faq 38

Yap. Although it's not so much the OS that's the bottleneck for me as it is the maximum size of AutoIt structs. I used to stuff my matrices in structs, which is fine in 32-bit up to 2 GB. But now I need larger containers, so this library provides me with an easy way to manage these (on x64), without either creating or mapping (AutoIt) structs. Of course, you could also stick a large file in there (e.g. to compute a hash, as trancexx has shown here), or use it as a large graphics buffer for animations, for example.

This is virtual memory, not physical memory. And I don't use all of it, I just need more than 4 GB in individual computations. Used memory pages get swapped in and out of physical RAM as needed. Explanation here. RE. your second question, not quite. This library is purely for x64 environments. It's a RAM allocation manager that pre-allocates a named space of desired size, in which you can then allocate smaller chunks that can be larger than 4GB each (identified by their base address) for your personal use. If you're mapping AutoIt structs to these (see second provided test script), these will still be restricted to 2GB (-1), but my E4A x64 dll is native-x64, so larger-sized matrices are also supported there. And when you subsequently release some of these chunks they can be re-assigned for new allocations, just like a file manager would for a harddrive. I cannot use AutoIt structs for matrices >2GB; that's why HighMem provides an alternative for larger chunks (but only in x64).

@MattHiggs: Hi, thanks. The problem I'm describing (running out of memory when trying to allocate multiple large chunks of data) occurs solely when running AutoIt scripts as 32-bit (even though I'm on x64 machine + x64 OS). But it would of course also occur on a 32-bit machine+OS. I haven't really tested this library in partial 32-bit environments, but as far as I can tell, you would need all three aspects (machine/OS/AutoIt) to be running in x64-mode for this to work. I presume that if you were to use the directive "#AutoIt3Wrapper_UseX64=Y" in a 32-bit environment (machine and/or OS), it would fail, and @AutoitX64 would still return False (0). If the OS is not x64, then how is AutoIt going to receive 64-bit memory pointers from it (which are needed to address the entire virtual memory space, in my case 128 TB (with 16 GB physical RAM))? Ditto for machine. Since my environment only required me to get the AutoIt part up to x64 standard (and my own Eigen4AutoIt.dll to be compiled for x64), that's what I did. It's because I deal with large datasets in large computations all the time, and so far my E4A library couldn't handle these in full, so I either had to write complicated segmented computational codes or develop a computation in E4A on a small dummy dataset, iron out all the kinks, and then translate that into a separate (C++) Eigen code (which is quite painful to debug, hence using E4A first, which is much more user-friendly). Using HighMem, that's all history now. (Well, except for the initial debugging, that is.) Another advantage of using this memory mapping (that I hadn't mentioned yet) is that it can be shared between processes, so conceivably parallelised processing becomes possible (even networked, if #RequireAdmin can be added to the script). So for me it was the next step. Not sure it can be of any use to others (such as yourself), but it's a safe bet to assume that in x86-mode (i.e., 32-bit), there's no point in using it as your mappable address space would be restricted to 2-4 GB, which is the standard Windows-allotted virtual RAM per process anyway. Does that answer your question?

E4A beta version 4.0 released. Are you sitting comfortably? Because this is going to take a while. This is E4A's biggest overhaul to date. I'll spare you the technical details (see ChangeLog), but users switching to this version (and future upgrades thereof) will notice some big improvements (providing it all works as it's supposed to ), notably: a user-friendlier set-up: E4A now relies on a simple INI file (Eigen4AutoIt.ini) for various operational settings, including variable $EIGEN_DLLPATH (full path where the dlls are located). So you never have to patch the source any more (unless you want to); just open the INI file in your favourite text editor to change settings, Save, and done. If absent in the local work directory, it will be generated with default values. Furthermore, several new functions allow you to query basic specs (dims, size, type) of matrices on file (without loading them first) and in memory. And if you've forgotten the exact name of a function, the number of alias wrappers is now close to one thousand. Finally, new flag $EIGEN_Verbose allows for status messages to be sent to console, especially in conjunction with the next item: HighMem integration: in x64 environments (machine+OS), AutoIt scripts running in x64-mode (by adding directive #AutoIt3Wrapper_UseX64=Y) will pre-allocate a user-defined amount of virtual memory at initialisation (see new operational variable $EIGEN_ALLOCATE_RAM_GB, also found in the INI file) for storing matrices. That means matrices can now be any size that fits into your virtual RAM (NB this is usually much more than your physical RAM; for example, I have about 128 terabytes (yes, TB) on my dinky old laptop). The usual limit of 2/3 GB per Windows process is thereby lifted. This is made possible by: full x64 support: new dynamic link library EigenDense_x64.dll runs in native 64-bit. That means 64-bit registers and memory pointers, and faster processing. Dll usage is automatically selected based upon the contents of macro @AutoItX64 at startup; just add the x64 directive at the top of your script, and you're set. Eigen's own version is upgraded to stable release 3.3.4 Gaussian statistics: probabilities, Z-scores, p-values, one-/two-sided, all you need to determine likelihoods, confidence intervals, and significance, given an underlying normal distribution. New Test script provided. Extensive Sort capabilities (see section "Transformation" in the Help): full matrix, row, col, diag, block, rowwise, colwise, and results stored either _InPlace or to new output. Courtesy of the boost libraries, so blazingly fast.The associated new test script compares _ArraySort with converting array to matrix, E4A-Sort, and convert back, which will be faster for sufficiently large arrays. Naturally, many aspects still await (more) thorough testing, reason why this is a beta release, and all the usual caveats apply. As the license states, do not use E4A in critical infrastructure or high-risk activities. Other than that, feel free to explore these new (and existing) capabilities to the full (I certainly am). Enjoy.

You might want to consider using this: It isn't free (the PDF library) as far as I recall, but it does contain a lot of functions like inserting images into PDFs. You can use _ScreenCapture_CaptureWnd to capture your window

krasnoshtan, The Managing Multiple GUIs tutorial in the Wiki will explain how to do this. M23

Do you not specify a ControlID on purpose? If you specify the ControlID you can drop the ControlSend($hWnd, "", "", ("{RIGHT}")) statement.

Maybe because you use variables $oExcel1 / $oExcel2 to hold the application AND the workbook object. Example: If FileExists($sExcelFile2) Then Global $oExcel2 = _Excel_Open () $oExcel2 = _Excel_BookOpen($oExcel2,$sExcelFile2) EndIF BTW: There is no need to call _Excel_Open two times. Call _Excel_Open after starting the script once and use the returned application object to open both workbooks.