Grimster

nevermind got it working. For some reason it was not reporting any @errors and now all of the sudden it works....

embedded web pages are URL-less IE windows that are Internet Explorer_Server class. Yes is a pain in the @ss to interact with them using autoit. Almost not worth the effort.

Yes we know the drivespacetotal command does not work right, thats the whole point of this thread.

This is 100% wrong, Hard drive manufactures do not "round off" the storage space on the drives they sell. If they advertise 500gb the drives they sell have EXACTLY 500,000,000,000 locations to store a byte.

I dont know what you are talking about, my correction is 100% perfect. I just tested it on another computer 40gb hard drive with only one user partition of c: Windows correctly report 37.2xxxxxxx BINARY gbs drivespacetotal incorrectly reports : 38146.49609375 mb. Incorrect in both binary and decimal My correction correctly report 39999.500288 in decimal Again, my correction does not show a perfect 40,000 mb because as stated Windows reserves a small hidden partiton of 8mb or 100mb.

It does not work like that. First you have to tell us what size drive you have and if you have more than one user created partition. If you got 299,961.93792 AFTER my correction then you have a 300gb hard drive (assuming you have not created any other partitions than c:) My correction does not show 300,000mb exactly because as stated Windows reserves a small hidden partion of 8mb for XP and 100mb for Win7 and Vista. What my correction does show is the EXACT and CORRECT decimal number of bytes on your c: partition or any other partition you please to seek the size of. If you desire to obtain the ENTIRE size of the drive (again assuming only one user partiton of c:) simply use the Round command to the nearest mb or gb decimal place AFTER my mathematical correction to the DriveSpaceTotal command

Now you're just making fun of me.....thats the EXACT same number.

I corrected my original post and the original code is now correct, please reread it now.

DriveSpaceTotal command reports the incorrect drive size. Whoever the person was who created this command has his/her math all wrong. They are clearly confused with the Binary bytes to Decimal bytes conversion. Currently all the command does is take a decimal representation of the current BINARY bytes and multiplies it only once by 1024 then simply moves the decimal place over to show MBs. That is an incorrect way to convert and produces a completely wrong answer. Here is the code/math to correct the incorrect math built into the DriveSpaceTotal command $HDspace = DriveSpaceTotal("c:") MsgBox(0,"incorrect hard drive space in Mbs",$hdspace);----before correction $hdspace = $hdspace * 1000000 $hdspace = $hdspace/1024 $hdspace = $hdspace/1000000 $hdspace = $hdspace*1024*1024*1024 $hdspace = $hdspace/1000000 msgbox(0,"Correct hard drive space in Mbs",$hdspace);-----after correction This correction will now give you the EXACT size of a partition. Note if you have only one user created partition like c: , even with the corrected math you will not get a perfect 120,000mb, or 500,000mb, or 1,000,000mb simply because Windows XP and Windows 7 reserve a small hidden partition of 8mb or 100mb which throws off the exact size of the ENTIRE drive. You can always use the Round command to round off the the nearest decimal point in MB or GB

Well geez thanks for letting us know in the documents. I mean who would think a command SPECIFICALLY for arrays would not work for an ARRAY created by _IETableWriteToArray. Autoit is good but it has some SERIOUS compatibility issues with its OWN commands. Why is this a problem? Because it creates complete LOGICLESS scripting.

This is getting ridiculous. You cant read a specific location from a 2D array created by _IETableWriteToArray. Array commands are not compatible with the array created by _IETableWriteToArray. #include <IE.au3> #include <Array.au3> $oIE = _IEAttach ("webpage with table", "WindowTitle") <---webapage selected with a table $oTable = _IETableGetCollection ($oIE, 1) <----Table 1 selected $aTableData = _IETableWriteToArray ($oTable, true) <---Table 1 written to 2D array _ArrayDisplay($aTableData, "$aTable") <--- Displays 2D array with info from table _ArrayToClip($aTableData, 2,2) <---ERRORs out. No command will read from the 2D array. MsgBox(0, "_ArrayToClip() Test", ClipGet()) "C:\Program Files\AutoIt3\Include\Array.au3 (1130) : ==> Array variable has incorrect number of subscripts or subscript dimension range exceeded.: $sResult &= $avArray[$i] & $sDelim $sResult &= ^ ERROR"

Whatever, I dont think so. The lack of essential points makes it hard for the beginner to learn these IE commands. Using the IE_Example in example scripts is illogical and does NOT correctly explain how the command is executed. Sure "Dale" maybe good at scripting in Autoit but far from good at teaching or explaining. As the saying goes, A poor teacher requires mind reading students. Humans are not mind readers....

I finally got it. #include <IE.au3> $oIE = _IEAttach ("Google - Microsoft Internet Explorer", "WindowTitle") $sText = _IEBodyReadText ($oIE) MsgBox(0, "Body Text", $sText) Still, the docs for IE management are simply awfully put together and explained. Get ride of the "_IE_Example " as this only makes things illogical when trying to learn the commands. Completely illogical.

I think you know as well it cant or is too difficult to be done. You have to admit its such a simple task and yet with all the commands its difficult or not even possible to be done.

This just does not not work. The autoit help docs are awful to explain IE Management. If someone can show me how to pull the text from say....www.google.com WITHOUT using the URL but with the IE window title then this would greatly help. Amazing how this such simple task looks as if it can not be done with all these commands.