TechCoder

what have you tried? you say you find nothing in the readme file (I will presume you mean the help file????) - what about Send() ???? a quick Google search for "autoit hold a key" produced several results that would have told you that.......

Have you tried doing an internet search to find help/clues - or just keep waiting for someone to hand you an answer???? Other than seeing yet more 'bump' posts from you, I took all of 3 minutes and saw several things that might be causing you difficulty - though since you don't post what version of Windows, IE or anything else you are running, it makes it just a wild guess where it might be as far as a Windows problem (of which several are listed - just do a search for the error message - loads of stuff on that........) (it is an access issue, though common trouble in certain Vista versions - oh, sooooo much one can learn from just a quick look.....) Another search you might do is based on the type of command you are trying to do - maybe even reading the documentation on it and perhaps getting an idea of a different command or way it might work differently. http://curl.haxx.se/libcurl/c/curl_easy_setopt.html As I showed in the other thread (which you also posted this same issue in.... ) and as it typical in UDFs, not 100% of the commands are supported, so sometimes you have to go about things in another way. In this case, I might suggest (from the documentation.....) that you try CURLOPT_PROXYPORT and not use the port in the original call. Now, if what you were looking for is a "hand me an answer", then, that won't be coming right away........ With the little info you provided other than "help me, help me".... - and a non-truthful IP address - which then can't be tested by anyone - if you really need to 'hide' that badly, then use a public address that is real and show the code that doesn't work to that one...... - the data you gave shows no initiative, only 'expectation of someone doing it for you'...... - doesn't set too well...... (getting too worked up to even make decent sentence structure....) - I really doubt anyone can give you much of a definitive answer.

That's why I put that statement in the top post - seems very odd behaviour and I wasn't sure how it would react. I left in all the W3C settings in case someone has an answer - felt it better to have them available than to make a 'perfect' user interface with only working items (then, someone would ask "why did you leave these out?"!) Would like other feedback on just how AutoIt works internally on the embedded IE - does it really use the IE from the user's computer (which I thought, but testing seems it doesn't) or a broken-down version (for speed, etc.) or what? Haven't researched it, but certainly the behaviour here is not consistent on the borders.

sure does........ still showed up until (not positive where exactly, but the steps are simple in case someone else comes across this); 1. removed the other option (in my case /soi) 2. Deleted the old 'merged' file 3. closed the main file 4. reopened the main file and compiled The merge_stripped file runs now. And compiles/runs. Thanks!

#Au3Stripper_Parameters=/mo /soi

stripped file using the download beta = 19338 lines stripped file using SciTE compile = 188 lines Interesting note (hope it helps) - stops at 20 errors - stops right after the call to the main function - the last error being 'undefined function' program runs fine with 'Go' - no errors uses mostly standard UDFs plus a couple from the forum and two I built. I can zip them all up and send them to you if needed.

"solved"? = dunno - runs quickly and drops off the screen I did a capture and see it says log says tried loading the stripped code and running in SciTE

SciTE Version 3.4.1 compiled fine in previous version and even this one, with though of course, some 'complaints' changed to run the Au3Stripper instead get this........

Win 7 Home Premium 64-bit - works fine

Below you will find both a new Marquee UDF (many W3C/HTML5 features and more) as well as a user-friendly program that both serves as an example script, as well as it will create the code for any particular marquee for you! Enjoy! ~~~~~~~~~~~~~~~~~ BACKGROUND on <marquee> ~~~~~~~~~~~~~~~~~ <marquee> has been classed as "non-standard" and "non-conforming" as an HTML element (http://www.w3.org/wiki/HTML/Elements/marquee) There is no promise that it will continue to be supported in the future, though it is obvious that many people have a need for this feature and it has remained in the major browsers for years..... <marquee> was originally built into Internet Explorer only, now supported in other browsers, though some original features do not work in IE either - it is clearly trying to be phased out, though a 'replacement' of sorts is coming around, using HTML5 components, so I think it will never totally go away. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For a project I'm working on, I need a way to create a LOT of different marquees. I thought it simpler to have a program create the code needed, and built the attached 'user interface' program using various references to the feature. THE USER PROGRAM IS BACKWARD COMPATIBLE WITH THE EXISTING UDF FROM Melba23 I also needed some features that are not part of the UDF from Melba23 that are direct references to current (HTML5) recommendations from http://www.w3.org/TR/CSS2/, so I modified the current UDF to create the additional functions, which make the UDF more HTML5 compliant (some of the features I built in have no HTML5 component, existing functions were updated only where needed for the first release - perhaps someday the rest can be done, though no immediate plans) ******************************************************************************************************************************* KNOWN ISSUES and/or LIMITATIONS within the user program - Tip text NOT IMPLEMENTED (from _GUICtrlMarquee_SetDisplay $sTipTxt) - I had no use for it in my project, though it is not difficult to add if you need to - border styles do not correspond to w3.org settings (not the program's fault...) This article (http://webdesign.about.com/od/beginningcss/a/aa091207.htm) states that IE does not support 'groove', 'ridge', 'inset' or 'outset' styles, yet does support 'dotted', 'dashed' and 'double'. Testing has proven this is true for IE (11), however, in testing AutoIt (with the Marquee UDF), which I thought uses IE (?), it appears that just the OPPOSITE of this is true. Another item for further testing/study......... - 'Align' feature not working 100% on all fonts (not the program's fault! the initial version of <marquee> (designed for IE and copied to other browsers later) contained an element called 'align', which has long been obsolete in favor of css 'vertical-align', however, it is not a direct replacement and does not work inside <marquee>. Several alternatives were tried (including 'line-height' and even 'vspace', which may also soon be phased out) and nothing works 'perfectly' (search the web on font sizing and spacing - you will see this is extremely difficult). This program works around these challenges in a 'best effort' way, using calculations and 'top-margin' (or vspace) spacing. 'Recommended' fonts (http://www.autoitscript.com/autoit3/docs/appendix/fonts.htm) will be set to 'center' or 'bottom' (within a pixel or 2), while other fonts may be off by several pixels (something in the font is different..). If you need the other fonts, a bit of testing would give some offset numbers that could result in better display. (this is NOT on my list to do, though maybe someone would want to take that on???) - You can create 'unreadable', 'unusable' and even 'UGLY' marquees (not the program's fault, either!) While a bit of effort was put into limiting things, there is no cross-checking to make sure your marquee will look 'nice'. All parameters within the marquee feature have been tested to their max/min limits (and pushed well past the documented limits for speed and delay - you can make a F A S T or S L O W marquee well outside the published specs!) and set accordingly. Any/all color scheme, font size, etc. can be used (no matter how horrible the outcome...) so have fun and create what you like! ******************************************************************************************************************************* Additional recommendations from w3.org built into Marquee_W3C.au3 UDF 1. Border thickness (width) refered as "thin", "medium" and "thick" or <length> (any number - to infinity) (http://www.w3.org/TR/CSS2/box.html#border-properties) (http://www.w3schools.com/jsref/prop_style_borderwidth.asp) Marquee_W3C UDF allows any number as an entry, as well as the more 'friendly' named terms 2. Border Style is included in Marquee_W3C UDF (not in the current UDF, therefore, none of the settings in the user program do anything if you use the old UDF, so it is set to $GUI_DISABLE.) 3. use of PIXELS and EM for formatting text instead of POINTS http://www.w3.org/TR/CSS2/fonts.html#font-size-props use <length> paramaters http://www.w3.org/TR/CSS2/syndata.html#value-def-length with named length units (em, ex, cm, in, px, etc.) POINTS are used in typsetting, while PIXELS, and EM are more correct methods of sizing fonts on modern monitors (one good article on this topic can be found at http://webdesign.about.com/cs/typemeasurements/a/aa042803a.htm ) NOTE: The user program is backward compatible with the UDF from Melba23 that uses POINTS and auto-sets the parameter with the chosen UDF. Marquee_W3C.au3 MarqueeMaker.au3

Welcome, 'hijacker' - I do hope you get a solution. What I found was that a 'best practice' on using AutoIt and SQLite was to actually avoid as many calls to the database as possible (in other words, the best way to have fast code is to not use the database - extremely counter-intuitive and kills a lot of brain cells trying to get around it, IMHO.... ) The slowdown (as I found in my testing) is in the calls to the .dll - not really anything that can be done short of a core code integration. I wound up (under jghd's directing 'whip' with a work-around by creating some complicated arrays using Enum, etc. to help relieve the 'pain' of only having numerical arrays available (there is a UDF for naming the array slots, but it adds quite a bit of time too - nice to use, but not recommended if you have any speed issues in other places.) And, I now go to the database once for a lookup (when the code starts, so it isn't really noticeable) and once when I write the 'massaged' data that needs sorting/selection (that I found no work-around for in AutoIt arrays) and then the "have to" dip of grabbing the complex sort, etc. that only the database can do. As I said before, it made me 'think' more about my programming, which I do believe has made me a better programmer, so, overall, worth the effort, though it doesn't make for "get it done" programs..... In your case, the query is complex enough that I'm not seeing a work-around that is feasible using AutoIt arrays - there isn't a great way to search and update arrays by matching multiple columns, etc. (that is what a database does very easily and well - I know...) and unless you can re-think your data layout and updates to match into arrays, you are destined to go through that painfully slow interface between AutoIt and SQLite. With that, I turn this topic over to you and look forward to hearing of your successes.

YUP! Exactly the issue. Went through and checked for "/" and "Round", etc. and added Int() around it - looks great! Of course, the background is now out of place a bit, but that is simple enough to fix (have to do the math in the same way instead of a separate equation - no biggie). This puts me back on track with the project - THANKS!

I've developed a full-screen program to interface with a calendar (allows the user to show current bookings, etc on a screen in the front office), however, having some trouble with the table. I'm looking for ideas on how to best 'attack' this in AutoIt. Writing this in php, using html tables, css, etc. it looks great. nice transparency, clean table lines, etc. However, in porting this to AutoIt, I'm having trouble getting the table to display clean lines, transparency and good text. I tried using an embedded html page (YUK - I have had better screens, but this is the 'best' with everything going on I want....) and also using the Table UDF ('?do=embed' frameborder='0' data-embedContent>> things are much better, but not happy with the lines... - I have a simlar issue as reported page-2#entry841285)'>page-2#entry841285) I'm happiest with the results from the Table UDF, but the odd black lines (on the shot above) appear here/there and change position depending on the data. When configured to display a colored border, the issue is still there and often shows up worse as the 'missing' pixel or two create a large border and often with the missing pixel inside. I chose the Table UDF because of the transparency, borders and easy-to-update text in each 'cell' - done as labels here (as I understand it, ListView, etc. can't do all that - I'm still pretty new with AutoIt and haven't learned all the best GUI bits yet). And, I'm very happy with the results, other than those odd lines (which are keeping me from releasing the product). Any suggestions on a better route to go to get nice, clean, no border, easily updated, transparent tables with AutoIt like the very easy to do html page?

"Interesting"? Perhaps the most interesting bit was the fact that jchd has more knowledge about sql in the tips of his little fingers that I have acquired in twenty-something years (well, maybe that isn't "interesting", but it certainly became very clear very quickly!) I'd say there where too many 'take-aways' from the PMs, etc. to possibly list, though we (I can only use that term loosely as it was much more "under much appreciated, patient guidance - even when I didn't want to believe it, but did it anyway and found it was right.....") found where the slowdown occurs, I learned a LOT about how/where to clean up my code (both in this project and in general for all projects since) and even though I wound up spending a couple weeks cleaning and reworking things, it was well worth the time and experience. Guess I hadn't really said THANK YOU (not publicly anyway), but I know if I have any further challenges with anything like this, jchd is very high on my list of 'go to' people. As for what was found? A portion of the slowness was my 'lazy' code. Once I cleaned that up, I sped things up a bit (don't have the numbers now, but it was something like 3% faster). The real significant time factor change was when I figured out the 'serious' slowdown was NOT SQLite and NOT AutoIt, but actually the INTERFACE between them (going through the .dll - massive time killer!) Once I learned that, the only answer to 'speed tweaking' everything was to do the massive rewrite to eliminate that from the program as much as possible (not easy for me as I've always done server-side code and running to the database with any sort of change has been my practice for years). End result? Moving everything from 'database reliant' to using arrays made the end product at least 'liveable' timewise. Still nothing like the php version (which is constantly calling the database), but we got it down to around 45 seconds for the total process. Also, to make the user presentation feel more 'speedy', I broke the processing in half and presented the user with the first report to look over, which happens 'quick', then we process the second half and give that report (the php version gives the reports on both portions at the end). Makes it feel like 'something is happening' a lot better. I believe I cut it down to something like three database calls instead of the dozen or so I was using for each run of the process. Constant testing of each feature/sort/etc. showed that it was possible to work with arrays for most things (my data requirements were 'on the edge' of really needing more than arrays would support, but I opted for speed over the 'edge' scenarios {ie., the customers that would kick into that area would likely be in a position to upgrade their system memory, etc.}) and where AutoIt doesn't really have quick functions (multiple sorting on cross-referenced data), I used the database, which excels in that. I guess the biggest 'take away' was just learning what tool to pick up for the right job - using each in the way it works best, for the job it was designed.

I think that relates well to the Spanish speaking students learning English in my classes - while it is my 'responsibility' to make sure they learn 'proper' speaking habits, it is also, and a more important responsibility to expose them to a variety of words, phrases and situations where it is then THEIR responsibility to apply those to situations they face in their own lives. There is no one way to do things, and making the help file extremely uniform, while in some ways preferable, would also eliminate the true sense of TEACHING - that there are things in this world that aren't simply answered in some manual. There are, in fact, some things that you must figure out for yourself! (that is not to say there aren't some 'improvements' I'd like to see in the help file, though uniformity in coding style is not one of them)