Re: RevCloud (was Re: Line Numbers in Text Editor)
Excellent, Richard, and worth waiting for. Thanks sqb On 29 June 2010 16:31, Richard Gaskin wrote: > And besides, there there's nothing to sell: RevCloud will be free. > > So here's the skinny: > > Over the last decade most of my projects have had between three and five > developers working on them, and the more I learn about this community the > more I realize these are pretty typical team sizes for the sorts of projects > for which Rev is a good fit. > > -- - Stephen Barncard San Francisco ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RevCloud (was Re: Line Numbers in Text Editor)
> RevCloud makes it easier to support multi-developer teams by providing a > collection of tools tailored specifically for the sort of work we do in Rev. > > Even better, the tools in RevCloud are just the icing. Beneath them is a > tasty layer cake of client and server libraries from which you can build all > sorts of other tools to support your team. > > I could write more about this, and will soon, but to keep this list on topic > I'll post those details in RevNet. This sounds really interesting Richard, and very much ON topic in my opinion. Please keep us in the loop. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RevCloud (was Re: Line Numbers in Text Editor)
stephen barncard wrote: On 26 June 2010 09:23, Richard Gaskin wrote: ... This keeps the stack file small enough to be extremely portable (I'm migrating a lot of tools to cloud storage - look for *RevCloud* coming soon to RevNet this summer; think devolution on serious steroids and focused on collaborative workflows)... RevCloud?? wha? ok Richard, you've opened the door now you must tell us more... ( I didn't want that to rhyme.) It's okay if what you wrote rhymes. It happens here from time to time. It might seem like something you should avoid, but too much effort would be paranoid. So if what you wrote comes out that way just be glad that it says what you had to say. :) I reluctant to put too much effort into selling things that aren't shipping yet. The proof will be in the pudding, and it won't matter much until you have a spoon in hand and are ready to taste it for yourself. But RevCloud's moving along well enough that it doesn't hurt to at least give a heads up about it. And besides, there there's nothing to sell: RevCloud will be free. So here's the skinny: Over the last decade most of my projects have had between three and five developers working on them, and the more I learn about this community the more I realize these are pretty typical team sizes for the sorts of projects for which Rev is a good fit. Such distributed workflows open up great opportunities to leverage collective knowledge and experience, but also present a variety of challenges in coordinating the team for optimal effectiveness. RevCloud makes it easier to support multi-developer teams by providing a collection of tools tailored specifically for the sort of work we do in Rev. Even better, the tools in RevCloud are just the icing. Beneath them is a tasty layer cake of client and server libraries from which you can build all sorts of other tools to support your team. I could write more about this, and will soon, but to keep this list on topic I'll post those details in RevNet. It'll be a few more weeks before the cake is out of the oven, as I have a couple pressing client deadlines to meet first. I'll drop a note here when RevNet has been updated -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Good stuff, Jeff. Thanks for posting that. In the olden days I had to be very careful about attempting to update things on scrollBarDrag because the performance hit was often quite noticeable, but on modern systems I must say I've been impressed with the combination of general system performance and the smart way the scrollBarDrag message is sent to support that sort of thing. Not long ago I needed to draw a series of polygons with certain shapes and locations relative to positions of chunks of text in a scrolling field. After some experimentation I was delighted to find out well it worked to do that dynamically on the fly, calculating and rendering the polygons in response to scrollBarDrag. But on that project I had one advantage I don't have with a script editor: the field I'm doing my calculations with is read-only, whereas a script editor's contents are dynamic. I also had no choice: in Rev, objects are limited to 32,767 px in height, but of course for a field with a lot of content I could (and did) easily wind up needing a polygon much taller than that. This is similar to the problem Trevor's DataGrid solves, in which contents that would be prohibitively tall can be rendered dynamically if needed. But since line numbers can be done in advance without difficulty it would not have occurred to me to render them dynamically. How responsive do you find that algo with carriage returns? If a script editor provides auto-indenting the returnInField message is already pretty well loaded with code, which is why I've been reluctant to add more to it with things like dynamic line numbers. Memory size is usually minimal with prefab line numbers since they generally take up a small fraction of the space of the script itself, and I would be reluctant to also page the script in an out of the field in response to scrollbarDrag for the complexity it adds and given that the engine's field buffering is some of the best in the biz. But if your experience is favorable it may well be worth exploring that in my next revision. Thanks again for the provocative take on this problem. One of the great things about Rev is the wide variety of ways a given problem can be solved. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv Jeff Massung wrote: I gotta say, my name is Jeff Massung, and I disapprove of that solution. ;-) I love everyone sharing their ideas, but this is one that's been a solved problem, well... for a very long time, and with a little math there's no performance issue what-so-ever, and there's no need to keep around a field with thousands of numbers in it. Think of what we know: * The size of our editor. * Where the scrollbar is. * The size of the font we're using. From this, there's very little we actually need to do. Even with the largest monitor on the planet and using the smallest (readable) font, the number of average lines visible to any user is well < 100. So, generally speaking, we should never need to do much more than count to 100 at any given point in time to update our "gutter" area containing line numbers. So, here's a little script taking from my editor. It assumes that the the gutter area is always sized to the same height as the editor, that the line height is fixed (read: we're not embedding images or changing the font size), and that the editor has line wrapping turned off. With a few tweaks it could work just fine with those features on, but for the sake of this discussion, we'll leave them off. on updateGutter local tHeight local tTextHeight local tScroll local tFirstRow local tRows -- wipe the gutter clean put empty into fld "Line Numbers" -- snag what we care about from the editor put the vScroll of fld "Editor" into tScroll put the effective textHeight of fld "Editor" into tTextHeight put the height of fld "Editor" into tHeight -- calculate the first visible line and the total number of visible lines put tScroll div tTextHeight into tFirstRow put tHeight div tTextHeight into tRows -- fill in the gutter with the line numbers repeat with tLine = tFirstRow to tFirstRow + tRows put tLine + 1 & cr after fld "Line Numbers" end repeat -- scroll the gutter (every so slightly) to match the editor set the textSize of fld "Line Numbers" to the textSize of fld "Editor" set the textFont of fld "Line Numbers" to the textFont of fld "Editor" set the vScroll of fld "Line Numbers" to tScroll mod tTextHeight end updateGutter That's pretty much it. Now we need to know when to update the gutter area. We need to update it when: * on scrollbarDrag (the editor) * when the we reset the editor to display something new * when we resize the editor (and subsequently the gutter) HTH,
Re: Line Numbers in Text Editor
I gotta say, my name is Jeff Massung, and I disapprove of that solution. ;-) I love everyone sharing their ideas, but this is one that's been a solved problem, well... for a very long time, and with a little math there's no performance issue what-so-ever, and there's no need to keep around a field with thousands of numbers in it. Think of what we know: * The size of our editor. * Where the scrollbar is. * The size of the font we're using. >From this, there's very little we actually need to do. Even with the largest monitor on the planet and using the smallest (readable) font, the number of average lines visible to any user is well < 100. So, generally speaking, we should never need to do much more than count to 100 at any given point in time to update our "gutter" area containing line numbers. So, here's a little script taking from my editor. It assumes that the the gutter area is always sized to the same height as the editor, that the line height is fixed (read: we're not embedding images or changing the font size), and that the editor has line wrapping turned off. With a few tweaks it could work just fine with those features on, but for the sake of this discussion, we'll leave them off. on updateGutter local tHeight local tTextHeight local tScroll local tFirstRow local tRows -- wipe the gutter clean put empty into fld "Line Numbers" -- snag what we care about from the editor put the vScroll of fld "Editor" into tScroll put the effective textHeight of fld "Editor" into tTextHeight put the height of fld "Editor" into tHeight -- calculate the first visible line and the total number of visible lines put tScroll div tTextHeight into tFirstRow put tHeight div tTextHeight into tRows -- fill in the gutter with the line numbers repeat with tLine = tFirstRow to tFirstRow + tRows put tLine + 1 & cr after fld "Line Numbers" end repeat -- scroll the gutter (every so slightly) to match the editor set the textSize of fld "Line Numbers" to the textSize of fld "Editor" set the textFont of fld "Line Numbers" to the textFont of fld "Editor" set the vScroll of fld "Line Numbers" to tScroll mod tTextHeight end updateGutter That's pretty much it. Now we need to know when to update the gutter area. We need to update it when: * on scrollbarDrag (the editor) * when the we reset the editor to display something new * when we resize the editor (and subsequently the gutter) HTH, Jeff M. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Richard, Fantastic primer on handling line numbers in Rev! Thank you! It's amazing how something seemingly so simple can have such a huge impact. That is what I love about programming, the elegance of creative solutions. - Justin On Jun 26, 2010, at 7:23 PM, Richard Gaskin wrote: > Justin Sloan wrote: > > I am planning to implement line numbers in a proprietary text editor > > that I wrote for in-house use. Problem is, I don't know how I am > > going to implement it. I thought about using a parallel text field, > > but there has to be an easier way. Any of you genius devs have any > > ideas? > > I forked the MC IDE's script editor many years ago to add, among other > things, line numbers. It was at the time the only script editor for Rev > which had line numbers, and having implemented this "advanced technology" > I can share with you a couple tips I learned: > > The line numbers are displayed in a separate field to the left of the editor > field, kept in synch with scrollbardrag handlers in each. Being a script > editor I also have another field in between them for marking breakpoints, but > you probably won't need that for other types of editing. > > I chose a separate field for the line numbers because it seemed a more > with-the-grain approach than attempting to put anything in the editor field > except for the script itself. In Rev, a script is just a block of text, so > my mandate for my editor was to maintain as close a relationship as possible > between what you see and what the engine expects. So the script is dumped > into a field, with no caches or other intermediaries to complicate the > scripter's relationship with the engine. WYGIWE - what you got is what > exists. ;) I have a McCabe algo for Rev (see note on RevCloud below) so I'm > sensitive to the impact of complexity in a code base. > > At first I went the route most other text editors use, in which the line > number field is populated dynamically to show only the lines present in the > editor field. But I found that when I got beyond a few thousand lines the > time it takes the engine to render the line number field became a performance > drag on my typing. So I went with having pre-populated numbers, which isn't > so bad since you can still see how many lines you have in your script by just > scrolling to the end and look at the last line number across from the last > line of script. > > But even pre-populating the line number field was not without some challenge, > since putting in 10,000 lines of numbers would not be sufficient for some > scripts, and added a lot of bulk to the editor stack file. > > So the final solution I went with was leaving the field blank when the stack > is saved, and populating it on preOpenStack with the number of lines of the > script + 5000. Since this is a one-time performance hit when the stack > opens, the impact on performance isn't nearly as noticeable as it was when I > was appending that list with each carriage return (has anyone younger than 40 > even seen an actual typewriter carriage? Odd nomenclature in the 21st > century, but I digress). > > This keeps the stack file small enough to be extremely portable (I'm > migrating a lot of tools to cloud storage - look for RevCloud coming soon to > RevNet this summer; think devolution on serious steroids and focused on > collaborative workflows), and it's unlikely that a person will type more than > 5000 lines during a given session with the editor open. > > But what if they paste more than 5k lines? I've trapped for that in the > Paste item and add another block of lines numbers beyond the number already > in the field + the number in the clipboard, so we stay a few thousand lines > ahead of the scripter. > > HTH - > > -- > Richard Gaskin > Fourth World > Rev training and consulting: http://www.fourthworld.com > Webzine for Rev developers: http://www.revjournal.com > revJournal blog: http://revjournal.com/blog.irv > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
RevCloud?? wha? ok Richard, you've opened the door now you must tell us more... ( I didn't want that to rhyme.) On 26 June 2010 09:23, Richard Gaskin wrote: > ... > This keeps the stack file small enough to be extremely portable (I'm > migrating a lot of tools to cloud storage - look for *RevCloud* coming > soon to RevNet this summer; think devolution on serious steroids and focused > on collaborative workflows), and it's unlikely that a person will type more > than 5000 lines during a given session with the editor open. > > -- - Stephen Barncard San Francisco ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Justin Sloan wrote: > I am planning to implement line numbers in a proprietary text editor > that I wrote for in-house use. Problem is, I don't know how I am > going to implement it. I thought about using a parallel text field, > but there has to be an easier way. Any of you genius devs have any > ideas? I forked the MC IDE's script editor many years ago to add, among other things, line numbers. It was at the time the only script editor for Rev which had line numbers, and having implemented this "advanced technology" I can share with you a couple tips I learned: The line numbers are displayed in a separate field to the left of the editor field, kept in synch with scrollbardrag handlers in each. Being a script editor I also have another field in between them for marking breakpoints, but you probably won't need that for other types of editing. I chose a separate field for the line numbers because it seemed a more with-the-grain approach than attempting to put anything in the editor field except for the script itself. In Rev, a script is just a block of text, so my mandate for my editor was to maintain as close a relationship as possible between what you see and what the engine expects. So the script is dumped into a field, with no caches or other intermediaries to complicate the scripter's relationship with the engine. WYGIWE - what you got is what exists. ;) I have a McCabe algo for Rev (see note on RevCloud below) so I'm sensitive to the impact of complexity in a code base. At first I went the route most other text editors use, in which the line number field is populated dynamically to show only the lines present in the editor field. But I found that when I got beyond a few thousand lines the time it takes the engine to render the line number field became a performance drag on my typing. So I went with having pre-populated numbers, which isn't so bad since you can still see how many lines you have in your script by just scrolling to the end and look at the last line number across from the last line of script. But even pre-populating the line number field was not without some challenge, since putting in 10,000 lines of numbers would not be sufficient for some scripts, and added a lot of bulk to the editor stack file. So the final solution I went with was leaving the field blank when the stack is saved, and populating it on preOpenStack with the number of lines of the script + 5000. Since this is a one-time performance hit when the stack opens, the impact on performance isn't nearly as noticeable as it was when I was appending that list with each carriage return (has anyone younger than 40 even seen an actual typewriter carriage? Odd nomenclature in the 21st century, but I digress). This keeps the stack file small enough to be extremely portable (I'm migrating a lot of tools to cloud storage - look for RevCloud coming soon to RevNet this summer; think devolution on serious steroids and focused on collaborative workflows), and it's unlikely that a person will type more than 5000 lines during a given session with the editor open. But what if they paste more than 5k lines? I've trapped for that in the Paste item and add another block of lines numbers beyond the number already in the field + the number in the clipboard, so we stay a few thousand lines ahead of the scripter. HTH - -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
On Jun 25, 2010, at 7:37 PM, Alex Tweedly wrote: The straightforward answer is using formattedText . but the deeper question is what line numbering you want for the lines when there is line-wrapping happening. For instance, if it is something like a source code editor, then the line numbers (IMHO) should be independent of the size of window currenty in use. For example, if I have the following text 1 My first line 2 this is a very long line of text that is going to be wrapped in a moment when I make the window narrow. 3 third line. Then when the window becomes narrow, do I *want* 1 My first line 2 this is a very long line of text that is going to be wrapped 3 in a moment when I make the window narrow. 4 third line. or do I want something like 1 My first line 2 this is a very long line of text that is going to be wrapped 2a in a moment when I make the window narrow. 3 third line. It really depends on whether you are numbering the lines of the window or the lines of the underlying text (or source code, or whatever); quite often, I suspect, it should be the latter. And in that case I don't know of any quick or easy way to figure out how the numbering should be done :-( -- Alex. In the latter case, the easiest way to approach the problem is to place the line numbers into the field itself with a tab delimiter. It's easy to get something like: 1 My first line 2 this is a very long line of text that is going to be wrapped in a moment when I make the window narrow. < 3 third line. (If you need the "2a" option, not so easy.) Then script around the problem of fetching text from the field by something like: function getlinetext lineNbrStart, lineNbrEnd set the itemdelimiter to tab repeat with n = lineNbrStart to lineNbrEnd put (item 2 of line n of fld "text") & cr after textList end repeat return char 1 to -2 of textList end getlinetext This doesn't avoid messiness in what happens when the user selects text in the field, but could be useful in some contexts, eg, a list field. The Rev IDE script editor uses two fields and doesn't try to sort out line wrapping -- the script field is dontwrap = true. If the rumors about a major revamping of the field object are true, maybe we can have built-in functions that give both the clickLine and the "formattedClickLine" -- ie, the line marked by the arrow in the example above would be clickline = 2, formattedclickline = 3 -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Hi Alex, I gave it a try: as revlet http://berndniggemann.on-rev.com/textLineNumbers/ as zipped stack http://berndniggemann.on-rev.com/textLineNumberStack/ is a proof of principle, seems to work though. Sometimes a little awkward :) regards Bernd Alex Tweedly wrote: > > The straightforward answer is using formattedText . but the deeper > question is what line numbering you want for the lines when there is > line-wrapping happening. For instance, if it is something like a source > code editor, then the line numbers (IMHO) should be independent of the > size of window currenty in use. > > For example, if I have the following text > > 1 My first line > 2 this is a very long line of text that is going to be wrapped in a > moment when I make the window narrow. > 3 third line. > > Then when the window becomes narrow, do I *want* > > 1 My first line > 2 this is a very long line of text that is going to be wrapped > 3 in a moment when I make the window narrow. > 4 third line. > > or do I want something like > > 1 My first line > 2 this is a very long line of text that is going to be wrapped > 2a in a moment when I make the window narrow. > 3 third line. > > It really depends on whether you are numbering the lines of the window > or the lines of the underlying text (or source code, or whatever); quite > often, I suspect, it should be the latter. And in that case I don't know > of any quick or easy way to figure out how the numbering should be done > :-( > > -- Alex. > > > > On 25/06/2010 08:25, Justin Sloan wrote: >> I went with using a parallel field to add line numbers and it is >> working well. However, rev only counts the line numbers based on the >> delimeter. So if word warp is turned on you end up with more lines >> then there are actual line numbers. >> >> Does anyone know of a way to count all the lines, even the lines that >> are wrapped and not separated by the delimeter? >> >> - Justin >> >> >> >> On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung wrote: >> >>> I used a parallel field in my Cryogen editor (http://massj.tumblr.com >>> for >>> video + screenshot). Worked out perfectly, and now that I've done it >>> that >>> way once, I actually wouldn't want to do it any other way in the future. >>> >>> Jeff M. >>> >>> On Thu, Jun 24, 2010 at 6:01 AM, Justin >>> Sloanwrote: >>> >>> >>>> I am planning to implement line numbers in a proprietary text editor >>>> that I wrote for in-house use. Problem is, I don't know how I am >>>> going to implement it. I thought about using a parallel text field, >>>> but there has to be an easier way. Any of you genius devs have any >>>> ideas? > -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Line-Numbers-in-Text-Editor-tp2266755p2269436.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
The straightforward answer is using formattedText . but the deeper question is what line numbering you want for the lines when there is line-wrapping happening. For instance, if it is something like a source code editor, then the line numbers (IMHO) should be independent of the size of window currenty in use. For example, if I have the following text 1 My first line 2 this is a very long line of text that is going to be wrapped in a moment when I make the window narrow. 3 third line. Then when the window becomes narrow, do I *want* 1 My first line 2 this is a very long line of text that is going to be wrapped 3 in a moment when I make the window narrow. 4 third line. or do I want something like 1 My first line 2 this is a very long line of text that is going to be wrapped 2a in a moment when I make the window narrow. 3 third line. It really depends on whether you are numbering the lines of the window or the lines of the underlying text (or source code, or whatever); quite often, I suspect, it should be the latter. And in that case I don't know of any quick or easy way to figure out how the numbering should be done :-( -- Alex. On 25/06/2010 08:25, Justin Sloan wrote: I went with using a parallel field to add line numbers and it is working well. However, rev only counts the line numbers based on the delimeter. So if word warp is turned on you end up with more lines then there are actual line numbers. Does anyone know of a way to count all the lines, even the lines that are wrapped and not separated by the delimeter? - Justin On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung wrote: I used a parallel field in my Cryogen editor (http://massj.tumblr.com for video + screenshot). Worked out perfectly, and now that I've done it that way once, I actually wouldn't want to do it any other way in the future. Jeff M. On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloanwrote: I am planning to implement line numbers in a proprietary text editor that I wrote for in-house use. Problem is, I don't know how I am going to implement it. I thought about using a parallel text field, but there has to be an easier way. Any of you genius devs have any ideas? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Hi Justin, Am 25.06.2010 um 10:49 schrieb BNig: > > Justin, > > look at the formattedText property of a text field. It gives you the the > text of a field and inserts returns where the line wraps otherwise. This way > you have a line count of the field which matches what you see and not the > number of returns. > > put the formattedText of field "myWrappingField" into temp > put the number of lines of temp or, if you are in a hurry: ... put the num of lines of the formattedtext of fld "Bernd's WrappingField" ... ;-) > regards > Bernd Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
Justin, look at the formattedText property of a text field. It gives you the the text of a field and inserts returns where the line wraps otherwise. This way you have a line count of the field which matches what you see and not the number of returns. put the formattedText of field "myWrappingField" into temp put the number of lines of temp regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Line-Numbers-in-Text-Editor-tp2266755p2268157.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
I went with using a parallel field to add line numbers and it is working well. However, rev only counts the line numbers based on the delimeter. So if word warp is turned on you end up with more lines then there are actual line numbers. Does anyone know of a way to count all the lines, even the lines that are wrapped and not separated by the delimeter? - Justin On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung wrote: > I used a parallel field in my Cryogen editor (http://massj.tumblr.com for > video + screenshot). Worked out perfectly, and now that I've done it that > way once, I actually wouldn't want to do it any other way in the future. > > Jeff M. > > On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan wrote: > >> I am planning to implement line numbers in a proprietary text editor >> that I wrote for in-house use. Problem is, I don't know how I am >> going to implement it. I thought about using a parallel text field, >> but there has to be an easier way. Any of you genius devs have any >> ideas? >> ___ >> use-revolution mailing list >> use-revolution@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-revolution >> > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Line Numbers in Text Editor
I used a parallel field in my Cryogen editor (http://massj.tumblr.com for video + screenshot). Worked out perfectly, and now that I've done it that way once, I actually wouldn't want to do it any other way in the future. Jeff M. On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan wrote: > I am planning to implement line numbers in a proprietary text editor > that I wrote for in-house use. Problem is, I don't know how I am > going to implement it. I thought about using a parallel text field, > but there has to be an easier way. Any of you genius devs have any > ideas? > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Line Numbers in Text Editor
I am planning to implement line numbers in a proprietary text editor that I wrote for in-house use. Problem is, I don't know how I am going to implement it. I thought about using a parallel text field, but there has to be an easier way. Any of you genius devs have any ideas? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
