Jump to content

Locodarwin

Active Members
  • Posts

    651
  • Joined

  • Last visited

Profile Information

  • Member Title
    Origin of Ouijas
  • Location
    The Jungles of Antarctica
  • Interests
    Music, art, science, philosophy, psychology, robotics, mechanics, engineering, philanthropy. Knowledge, in other words.

Recent Profile Visitors

1,064 profile views

Locodarwin's Achievements

Universalist

Universalist (7/7)

1

Reputation

  1. Most excellent! Problem solved. Thank you kindly. -S
  2. Ok, I need some help finding a destination in Cartesian XY space. My math skills aren't what they used to be. This will probably be easy for someone in high school but that was many, many moons ago for me. I need a function that, given the following parameters, will find the destination coordinates. 1. Origin as Cartesian coordinates. 2. Distance from origin in Cartesian units. 3. Direction (in degrees, 0 to 360) from origin. For example, if I send the function an origin of (-2x, 2y) with a distance of 4 and degrees of 270, the function should return destination coords of (2x, 2y). The function should return the destination coordinates as a two-element array. Thanks in advance. -S
  3. Along with all the other reasons already stated, I think this ruins the point of the site as well for the sake of your own vocabulary. After all, if you'd been doing it without the bot, your vocabulary would be increasing every day by a startling amount. Doesn't that seem like a worthwhile way to give rice? I'm just saying. Plus, I just passed level 48 as I write this post, and I'm interested in seeing who here can do that without cheating. Yeah, it takes a while, but anyone can with enough persistence. You'll be smarter for it. -S
  4. I have been a participant in the migration from a Visual Source Safe environment to Team Foundation. It isn't simple, but it's straightforward. MS has a clear set of migration instructions that worked for us almost flawlessly. The only thing that gave us a problem, if I recall correctly, is how we processed backup/archived projects, since we were doing it in kind of a non-standard way. The rest of it was simply following directions. We don't use InstallShield so I can't help you there. Of the things on your list, this one probably matters the most, since the build process is different between the two environments, and thus you may have packaging woes. Probably not but best to be aware at least. We use Bugzilla (and we hate it, btw) for defect tracking. Does TestTrack integrate at all with VS or VSS? If so, it might be worth doing some research on. NAnt scripts, custom scripting, associated text files, other kinds of MAKE or BUILD-type scripting, should be no problem. MS really wants you to do it their way, though. It's less worrisome, of course, if you have one or more spare/backup environments. Either way, a code freeze and a couple days of work should have you going. -S
  5. Team Foundation is great for projects with any number of people; it scales really well, though, to extraordinary large teams like we have where I work. It's basically Source Safe on steroids. The project reporting and tracking features are above and beyond other source control systems I've used. But it can be kind of clunky and it's not as simple to use overall. On the client side, it bolts right onto VS. On the server side, it's the standard 3-tier system with a pretty simple setup process. I'd say it's about as easy to get going as SharePoint. -S
  6. In order to make these things happen, AutoIt would have to grow out of its scripting roots and become a compiled language. As was said, it's just too slow to expect 3rd parties to consider it acceptable as a supportable development "platform." Not that I'm not interested in such a thing. In fact, I'm very interested. The syntax and usability of AutoIt lends itself nicely to a revolution in compiled languages. The UDF concept and implementation itself is pretty innovative, the way it's done with AutoIt. It's just that the work it would take to make it a compiled language is monumental. The compiler would be a different beast altogether from the scripting language. The routines are already there, though...they'd just have to be refactored. The best idea would be to crunch down to assembly (NASM or similar). I have a working test right now that converts some of the simpler keywords and functions down into NASM, and compiles with a console EXE wrapper. It sounds pretty good, the more I think about it and play with it. Prototype your program in interpreted AutoIt first, then compile it to machine code once it's properly debugged. Hmm. Overall your proposal isn't hitting the mark, though. On the one hand you suggest getting together with Open Source communities. On the other hand you suggest licensing fees. While I get the overall sentiment of your argument, the details are a little hazy and sound too political. One thing I've noticed about the developers here - for better or worse, they're not really interested in taking the language much further than where it's at. Or that's the feeling I get, anyway. -S
  7. The best way to do it is to open both documents (workbooks) via the UDF separately. Don't open more than one workbook per application instance. That way you have an explicit reference for each document. I wrote the UDF this way on purpose, to dramatically simplify programming Excel. Excel COM is very flexible and will let you specify application objects, workbook objects, and worksheet objects in so many ways it'd make your head spin. Each of these three object types alone are at a different level of the object hierarchy, and thus each would necessitate different ways of writing up the UDF. You'd end up having to make extra commands and put even more parameters into the existing commands. Well, that's a lot of extra commands and parameters. The library is already pretty big. I find that if you stick to 1 application instance with 1 workbook object per application instance, you get the best overall results with the least amount of coding effort. Play by those rules and the UDF will flawlessly do what you need to do. -S
  8. FYI, "UsedRange" is unreliable and buggy, according to many experts. The recommended approach for returning the used range is found in _ExcelSheetUsedRangeGet(). -S
  9. Yes, it is. You're attempting to address rows with the wrong function. Use _ExcelRowHeightSet() for rows (1:80) and _ExcelColWidthSet() for columns (A:ZZ). -S
  10. Charts are a little involved and I haven't gotten around to wrapping them into a UDF. I'll get to it at some point. In the meantime, you can use Randallc's _ExcelCOM, which facilitates charting. As well, if you record a macro of you making a chart, and paste the resulting VBA code here, I can pretty quickly convert it into AutoIt code. If nothing else, you can use it as starting point for programming your own charts. -S
  11. Or just use what's in the UDF: _ExcelColWidthSet($oExcel, "A:IV", "autofit") _ExcelRowHeightSet($oExcel, "1:999", "autofit") Replace the "IV" and "999" portions with whatever your last columns and rows are. You can use _ExcelSheetUsedRangeGet() for that. Good luck with your Excel endeavors. -S
  12. Steve8tch, Thanks for the positive feedback. I intend to write pivot table routines Any Day Now, and definitely as a separate UDF, considering the work involved and the specialized and advanced nature of pivots. Wrapping the pivot table routines will be no small feat. If you're absolutely chomping at the bit in the meantime, and your particular problem can be solved with the PivotTableWizard function (which is pretty good and can cover most cases), then consider the following reference information on it: Function: $oExcel.PivotTableWizard([sourceType], [sourceData], [TableDestination], [TableName], [RowGrand], [ColumnGrand], [saveData], [HasAutoFormat], [AutoPage], [Reserved], [backgroundQuery], [OptimizeCache], [PageFieldOrder], [PageFieldWrapCount], [ReadData], [Connection]) -------------------------------------------------------------------------------- Quickly creates a pivot table and returns a reference to the created PivotTable object. SourceType An xlPivotTableSourceType constant indicating the source of the data to use in the pivot table. Can be xlConsolidation, xlDatabase, xlExternal, or xlPivotTable. SourceData If SourceType is xlConsolidation, xlDatabase, or xlPivotTable, a Range object containing the source for the pivot table. If SourceType is xlExternal, an array containing the SQL query string used to retrieve the data for the pivot table. TableDestination The Range object indicating the location of the upper-left corner for the new pivot table. TableName A name to assign to the pivot table. Default is PivotTablen. RowGrand True displays grand totals for rows; False omits row totals. Default is True. ColumnGrand True displays grand totals for columns; False omits column totals. Default is True. SaveData If SourceType is xlExternal, TRue reads all of the fields from the data source and False delays retrieving the data until the pivot cache is refreshed. Default is True. HasAutoFormat True automatically adjusts column widths when the pivot table is refreshed; False preserves column widths when the table is refreshed. Default is True. AutoPage If SourceType is xlConsolidation, true automatically creates a page field for the consolidation. Reserved Do not use this argument. BackgroundQuery If SourceType is xlExternal, True queries the data source asynchronously when refreshing the pivot table; False performs synchronous queries. Default is False. OptimizeCache True optimizes the pivot cache; False does not optimize. Default is False. PageFieldOrder The order in which page fields are added to the page area of the pivot table. Can be xlDownThenOver (default) or xlOverThenDown. PageFieldWrapCount The number of page fields per column in the page area of the pivot table. ReadData If SourceType is xlExternal, true reads all of the fields from the data source; False delays retrieving the data until the pivot cache is refreshed. Default is True. Connection If SourceType is xlExternal, the ODBC connection string used to connect to the external data source. --------------------------------------------------------------------------------------------- You'll have to convert the xlConstants used above and use the "Default" keyword for parameters you don't want to specify (or where the above tells you not to specify). The rest should be pretty straightforward. Just open your document containing all the data, and at some point call this function. You can use the code examples in some of my range-specifying parameters to see how to create the range objects needed to make this function work. Otherwise, you're stuck waiting until I can build the necessary library of routines. -S
  13. What sort of formatting? Size? Text wrapping? Joining? Colors? Borders? There are functions for a number of different formatting options. -S
  14. @GEOSoft: It sounds like your Excel installation has some sort of issue. I've not heard of any of the examples not running for anyone with Excel installed. Are there other machines you can try, as a sanity check? @Kerros: Actually I like like your function, and even though you admit you've leveraged from my functions to get it working, this is exactly the sort of help I envisioned getting since I started. Thanks for your contribution! It'll be added to the next iteration of the UDF. -S
  15. Two options. 1. Open Excel manually, right click on a cell, then choose Format Cells. On the Number tab, select the "custom" option and look through the list. Use one of the strings provided there or leverage them to build a string that'll work for you. 2. Google: http://www.ozgrid.com/Excel/CustomFormats.htm -S
×
×
  • Create New...