From thykeeper at nerdshack.com Sun Oct 14 08:26:21 2007 From: thykeeper at nerdshack.com (Brother Josef) Date: Sun, 14 Oct 2007 19:26:21 +0700 Subject: [WASTE-list] Text Filter callback Message-ID: <8332A346-95C4-42BE-93A2-E1A8C65DA704@nerdshack.com> It was my understanding that returning false from the text filter hook would prevent WASTE from inserting the character but my callback is not producing these results. If that is not the usage of the callback how can I achieve these effects? thank you. Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.piovanelli at pobox.com Sun Oct 14 14:25:59 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Sun, 14 Oct 2007 20:25:59 +0200 Subject: [WASTE-list] Text Filter callback In-Reply-To: <8332A346-95C4-42BE-93A2-E1A8C65DA704@nerdshack.com> References: <8332A346-95C4-42BE-93A2-E1A8C65DA704@nerdshack.com> Message-ID: <20071014182559.538310567@relay.pair.com> On Sun, 14 Oct 2007 19:26:21 +0700, Brother Josef (thykeeper at nerdshack.com) wrote: >It was my understanding that returning false from the text filter >hook would prevent WASTE from inserting the character but my callback >is not producing these results. If that is not the usage of the >callback how can I achieve these effects? thank you. No, returning false from the text filter hook tells WASTE that no filtering was performed, and the original text should be processed as usual. If you want to prevent WASTE from inserting the text, you need to set the text handle size to zero, and return true from your hook, like this: Boolean MyTextFilter ( ComponentInstance inTextInputComponent, Handle inFilterableText, UInt32 inModifiers, UInt32 inKeyCode, WEReference inWE ) { SetHandleSize(inFilterableText, 0); return true; } HTH, -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From thykeeper at nerdshack.com Tue Oct 16 19:47:56 2007 From: thykeeper at nerdshack.com (Brother Josef) Date: Wed, 17 Oct 2007 06:47:56 +0700 Subject: [WASTE-list] Text Filter callback In-Reply-To: References: <8332A346-95C4-42BE-93A2-E1A8C65DA704@nerdshack.com> Message-ID: <6B39A9B5-F980-4B9C-B7CE-F4E791C48529@nerdshack.com> I was using the filter to operate on key codes but I never did learn how to get a ASCII character from a UniChar in a decent way. I know I could wrap it into a CFString and convert the character from there, but that's a lot of code for such a simple operation. that snippet seems to accomplish that but i'm not sure what "reinterpret_cast" is. Is there a common utility for this? thanks again. On Oct 14, 2007, at 8:11 PM, Alfred Van Hoek wrote: > > On Oct 14, 2007, at 8:26 AM, Brother Josef wrote: > >> It was my understanding that returning false from the text filter >> hook would prevent WASTE from inserting the character but my >> callback is not producing these results. If that is not the usage >> of the callback how can I achieve these effects? thank you. >> >> Regards, >> Josef >> > > > returning true should tell WASTE to not insert the text, example: > > > // special case > if ( GetHandleSize ( inFilterableText ) == sizeof ( UniChar ) && > * reinterpret_cast < const UniChar * > ( * > inFilterableText ) == '\t' ) > > > // we need to make sure Waste is not handling the tab key input > // in order to do so we need not only return true, telling Waste > // we have handled it, but also we need to set the handle size to > // zero. This will ensure that the your runtime can handle the > tab key > // event. In this case, advancing the focus. > > SetHandleSize(inFilterableText, 0); > > return true; > > Alfred Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanhoek at mac.com Sat Oct 27 18:10:41 2007 From: vanhoek at mac.com (Alfred Van Hoek) Date: Sat, 27 Oct 2007 18:10:41 -0400 Subject: [WASTE-list] calculating linebreaks Message-ID: First of all, Waste 3 automatically recalculates line-breaks when necessary, while in Waste 2 we need to tell waste it by calling WECalText. No problem. However, recalculating line-breaks when the destination rectangle changes leads to spurious mistakes. We claim that the mistake is in the line break algorithm. Here is the code that will be called during a life resize: /* remember offset of first visible character */ WEGetViewRect(&lr, text); // the old view rect topCharPosition = *(LongPt*)&lr; // old topChar offset topCharOffset = WEGetOffset(&topCharPosition, &edge, text); dprintf("rewrapping: topCharOffset = %i, edge = %i, view left = %i, view top = %i", topCharOffset, edge, lr.left, lr.top); /* reset destination rectangle and recalculate line breaks */ _SetDestinationRect(instance); _SetViewRect(instance); if ( (err = WECalText(text)) != noErr ) { dprintf("error calculating line breaks..."); goto cleanup ; } lineWidth = WEGetMaxLineWidth(text); /* scroll the destination rectangle to keep the previous */ /* first visible character at the top of the view rectangle */ WEGetPoint(topCharOffset, kHilite, &topCharPosition, &lineHeight, text); dprintf("rewrapping: topCharPosition = %i, %i, lineWidth = %i, lineHeight = %i", topCharPosition.h, topCharPosition.v, lineWidth, lineHeight); // note that sometimes the topCharPosition is way off with respect to topCharOffset // and potentially is related to WECalText doing something wrong?? WEGetDestRect(&lr, text); offsetX = controltop.h - topCharPosition.h; offsetY = controltop.v - topCharPosition.v; dprintf("offsetX %i, offsetY %i", offsetX, offsetY); WEOffsetLongRect(&lr, offsetX, offsetY); WESetDestRect(&lr, text); cleanup: ; A good pass through the above gives: rewrapping: topCharOffset = 1728, edge = 0, view left = 8, view top = 37 rewrapping: topCharPosition = 8, 613, lineWidth = 312, lineHeight = 16 offsetX 0, offsetY -576 and the next pass gives: rewrapping: topCharOffset = 1728, edge = 0, view left = 8, view top = 37 rewrapping: topCharPosition = 324, 485, lineWidth = 391, lineHeight = 16 offsetX -316, offsetY -448 and suddenly the field is scrolled to the left. This offsetX change relates to the length of the word used in the field. The example used was: WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset WEGetOffset etc and the field width was less than 5 words. When the field width is increased to 5 words, Waste is moving the dest rectangle 4 words to the left if that would be of value here (Waste 2) or 2 words to the left (Waste 3). Then moving to a width that can contain 6 of the above words on a line, the field snaps back to an offsetX of 0: rewrapping: topCharOffset = 1728, edge = 0, view left = 8, view top = 37 rewrapping: topCharPosition = 8, 421, lineWidth = 470, lineHeight = 16 offsetX 0, offsetY -384 With Waste 2, but snaps further to the left as a function of the word length. Any thoughts, comments, workarounds etc? Alfred -------------- next part -------------- An HTML attachment was scrubbed... URL: From blgl at scoop.se Mon Oct 29 09:26:37 2007 From: blgl at scoop.se (Bo Lindbergh) Date: Mon, 29 Oct 2007 14:26:37 +0100 Subject: [WASTE-list] Special line breaking behaviour wanted Message-ID: <6CD5AD67-B5AE-43BA-9ECF-CADF69F98E99@scoop.se> This is easier to show than to explain in words: http://217.78.40.206/~blgl/widths.mov Can you get WASTE 3 to behave like this? /Bo Lindbergh From ryan at web-scripter.com Tue Oct 30 02:15:30 2007 From: ryan at web-scripter.com (Ryan Joseph) Date: Tue, 30 Oct 2007 13:15:30 +0700 Subject: [WASTE-list] 3.0 editing speed Message-ID: <954FE53A-A714-494E-B775-540EEB5A900F@web-scripter.com> Is it known that WASTE 3.0 has unusable delays when editing large files (10,000+ lines)? I just spent all morning looking for a speed problem in my code when I opened the WASTE demo to find the same thing. This problem did not exist in 2.0. Any plans to fix this or work arounds? Regards, Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.piovanelli at pobox.com Tue Oct 30 07:58:03 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Tue, 30 Oct 2007 12:58:03 +0100 Subject: [WASTE-list] Text Filter callback In-Reply-To: <6B39A9B5-F980-4B9C-B7CE-F4E791C48529@nerdshack.com> References: <8332A346-95C4-42BE-93A2-E1A8C65DA704@nerdshack.com> <6B39A9B5-F980-4B9C-B7CE-F4E791C48529@nerdshack.com> Message-ID: <20071030115803.1783662309@relay.pair.com> On Wed, 17 Oct 2007 06:47:56 +0700, Brother Josef (thykeeper at nerdshack.com) wrote: >I was using the filter to operate on key codes but I never did learn >how to get a ASCII character from a UniChar in a decent way. ASCII is a proper subset of Unicode, and the initial range of Unicode characters (0..127) maps directly to ASCII. Comparing a UniChar (= a UTF-16 code unit) to an ASCII control character like tab, line feed of carriage return is kosher. >I know I could wrap it into a CFString and convert the character from there, >but that's a lot of code for such a simple operation. that snippet >seems to accomplish that but i'm not sure what "reinterpret_cast" is. reinterpret_cast(EXPRESSION) is just one of the many C++ ways to write a typecast. Kind of like (TYPE)EXPRESSION in plain C, or TYPE(EXPRESSION) in Pascal. My sample code was simply comparing the first element of the filterable text handle (viewed as an array of UniChars) against the tab character. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down. From marco.piovanelli at pobox.com Wed Oct 31 13:06:51 2007 From: marco.piovanelli at pobox.com (Marco Piovanelli) Date: Wed, 31 Oct 2007 18:06:51 +0100 Subject: [WASTE-list] 3.0 editing speed Message-ID: <20071031170651.1377341949@relay.pair.com> On Tue, 30 Oct 2007 13:15:30 +0700, Ryan Joseph (ryan at web-scripter.com) wrote: >Is it known that WASTE 3.0 has unusable delays when editing large >files (10,000+ lines)? I just spent all morning looking for a speed >problem in my code when I opened the WASTE demo to find the same >thing. This problem did not exist in 2.0. Any plans to fix this or >work arounds? I'm aware of this problem, and I'm working on a fix. -- marco -- It's not the data universe only, it's human conversation. They want to turn it into a one-way flow that they have entirely monetized. I look at the collective human mind as a kind of ecosystem. They want to clear cut it. They want to go into the rainforest of human thought and mow the thing down.