i dont know if this will answer your questions but it should... Table fields (not revtable objects) are more complicated yet simpler...
The one field variable multicolumn is best shown when you set it's tabstops properties to the width of each column as "10, 30,60" set the tabstops of fld x to "10, 30,60" Then if you set the h and vgrid of the field (not the showlines) you will see the grid! It's definitely very neat! set the hgrid of fld 1 to true the fixedlineheight unfortunately must be on - so you can't vary row width like you can with columns (great shortcoming)... Only problem is that any column is a number, oriented rightwards, it can't be done (not in a serious way at least unless you like Courier-like monospace fonts so you can add spaces before the number to simulate orientation (but then why do you need table fields if you like doing that? yuk idea of old console file programming...). Table fields only ork in left-oriented manner, not centered or right tabstopalignments - so no decimal tab alignment either which is helpful to make nice presentations with numbers of different precision decimals - or for financial tables in percentage gains - we can format the number but we just can't control it's placement with table fields is the point... ..in other words, useless for the usual printable invoicing or ordering application (unless you want to look lefty or newbie in the face of your clients - maybe you have that quality of "who-cares" which i envy a few in some cases - but in business... So multiple fields are innevitable but NOT mandatory... Normal tables can be helpful in plenty of places elsewhere - but at the serious level, it's better to use multi-field tables if numbers are involved. - Tip: dont keep your data in your fields, keep a separate array in memory, this will help a lot in the long run... Remember 10000 of anything in rev can slow you down... or your client... But Rev has so many tricks... There's a few features most "common applications" have where rev could really do some improvements. But i guess meanwhile we do have to do it ourselves. Presentation matters to me - something where rev requires sometimes lots of sweat to find a simple solution - if there is one - usually there is! So i like to use multiple fields if there's numbers but not if there's more than 20 fields - depends how critical it is - also fields cannot display 20000 columns if they have a minimum of 2 letters in each column! It's simple, fast but definitely far from perfect (as in excel). It can get slow and the movie you're watching, the file you're copying while multitasking on your cpu will go in pause or rattle mode anytime you scroll the fields... BUT, table fields are quite simple... All you need to do is set the columns one up and your done! No synchronizing the scrolls, the hilites... Correction, you do if you use a table field header and have text scrolling past the right side of the field ;)!!! Then there's RevTableFields... A super table object i hear. But messing with it was not "as expected" - so i opted to my own again. So wrap your own system (or see those others will propose - develop your style or use something like TAOO which has most of these already - i could throw another 10-20 Ks of table and synch scripts if you want... ;), learn by doing is the best way, improve on your scrolling table techniques and see which is better... Avoid setting backcolors on the fields - not usually what you expected. Pending i think To get a "multi-field" horizontal-scrolling effects, group them fields, set the locklocation of the group to true and set the width of the group to the width of your card (or al gusto) and last set the HScrollbar of the group to true to see your fields scroll left and right. Some little things to adjust you will have to but it's definitely a cool trick - Tricking a rightmost vertical scrollbar shouldn't be hard to do - but you can't use the group's scrollbar... you can create one or use a geometry trick to show the significant scroll field. - If you do use the group's vertical scroller, you will need non-scrolling fields all at the right size but i predict it will need to keep the huge fields graphic in memory to scroll them later thus affecting cpu load and refresh tricks you might need later Programming it the object oriented way If you use one table field, it's easy... all interaction scripts can be in the field or in the card. But if you group many fields, it gets tedious to update fields script later doesn't it? So put the scripts into the group that contains the row of fields. The target function will tell you who got clicked or what needs focus... The parent tells the children what to do based on the subject's answer or state as i call this in TAOO - that's how i see programming in rev ;) http://monsieurx.com/taoo - more than just a dozen table handlers, a dozen for each control and for each function times each other ;) _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
