Re: 5000 lines of code
Richmond, you could rewrite that to be much more efficient, both in code, and I'm guessing in performance. Instead of this: case (numToChar(2339) numToChar(2325)) set the unicodeText of fld fPROC to numToChar(61953) put 2 into DDROP break case (numToChar(2339) numToChar(2326)) set the unicodeText of fld fPROC to numToChar(61954) put 2 into DDROP break case (numToChar(2339) numToChar(2327)) set the unicodeText of fld fPROC to numToChar(61955) break etc. Do this: First, set up a custom property (or preference file, if you like). It should contain this: numToChar(2339) numToChar(2325) tab numToChar(61953) numToChar(2339) numToChar(2326) tab numToChar(61954) numToChar(2339) numToChar(2327) tab numToChar(61955) etc. Then during startup, do this: global fPROCTable put the fPROCCustomProc of this stack into fPROCTable split fPROCTable by cr and tab Then, in place of that amazing switch statement, use this one line of code: set the unicodeText of fld fPROC to subTable[the unicodeText of fld fBUILT] If you also want to set DDROP then you could tweak that first array or just create a second array, which is probably better. The line of code for that would be something like: if DDROPTable[the unicodeText of fld fBUILT] is not empty then put DDROPTable[the unicodeText of fld fBUILT] into DDROP regards, Geoff On Sun, Jun 5, 2011 at 10:13 AM, Richmond Mathewson richmondmathew...@gmail.com wrote: If anybody really cares here is a PDF of the code in ONE object in my Devawriter Pro: read it and weep . . . :) http://andregarzia.on-rev.com/**richmond/PRO/KODE/5000.pdfhttp://andregarzia.on-rev.com/richmond/PRO/KODE/5000.pdf you never know; you might learn something, get a headache, or both! __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
Mark Took me a couple of times through that to get what you meant. Ah... you mean that same switch code is duplicated in other objects as well. What I'd do in that case is move it out of the objects and make a handler farther along the message path (the stack script, for instance) as command ParseIt switch blahBlahBlah end switch end ParseIt then in the mouseUp handlers just say on mouseUp ... ParseIt ... end mouseUp it's make maintenance much easier and your stack will lose a bit of flabbiness in the process. It certainly seemed like good advice until I tried what you suggested: I moved the recyclable code into the stack script and called it from each object. BUT, the interesting thing as that, while the objects called the code successfully, it meant that the individualised segments of code in the object that came after the recyclable code stopped working properly. This is a right bu**er as your advice would have meant I could reduce my file size considerably. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
I moved the recyclable code into the stack script and called it from each object. BUT, the interesting thing as that, while the objects called the code successfully, it meant that the individualised segments of code in the object that came after the recyclable code stopped working properly. Did you try referencing variables instead of passing them as parameters? Usually if you call a function (or a handler) and have it return something, it will be a single string which can be used to update a single variable in the calling handler. In the case of multiple variables that need to be updated, consider using reference parameters, therefore the calling handler will already have the updated contents of each variable. Example is shown in the dictionary by finding @ The character @ is placed before a parameter name to pass a reference to the parameter instead of its value. Pass a parameter reference when you want a handler to change a variable in the calling handler, or when you want a handler to return more than one value. Hope this helps On Jun 9, 2011, at 2:18 AM, Richmond Mathewson wrote: Mark Took me a couple of times through that to get what you meant. Ah... you mean that same switch code is duplicated in other objects as well. What I'd do in that case is move it out of the objects and make a handler farther along the message path (the stack script, for instance) as command ParseIt switch blahBlahBlah end switch end ParseIt then in the mouseUp handlers just say on mouseUp ... ParseIt ... end mouseUp it's make maintenance much easier and your stack will lose a bit of flabbiness in the process. It certainly seemed like good advice until I tried what you suggested: I moved the recyclable code into the stack script and called it from each object. BUT, the interesting thing as that, while the objects called the code successfully, it meant that the individualised segments of code in the object that came after the recyclable code stopped working properly. This is a right bu**er as your advice would have meant I could reduce my file size considerably. Jim Ault Las Vegas ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
Richmond- Sunday, June 5, 2011, 8:13:27 AM, you wrote: If anybody really cares here is a PDF of the code in ONE object in my Devawriter Pro: read it and weep . . . :) That may be the longest mouseUp handler / switch statement I've ever seen g A few suggestions: I'm not sure if it will make a difference in a mouseUp handler since you're limited by mouse movements, but you might want to lock the screen before and unlock it at the end since you're dealing with field contents directly. This will especially speed up your do command and updating field fRESULT. Also, you spend a lot of effort making sure that DDROP has the correct value, but then you never use it. I'm sure there's some way to collapse this using a lookup table, but I can't imagine what it would be. That's quite a handler. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
On 06/05/2011 10:03 PM, Mark Wieder wrote: Richmond- Sunday, June 5, 2011, 8:13:27 AM, you wrote: If anybody really cares here is a PDF of the code in ONE object in my Devawriter Pro: read it and weep . . . :) That may be the longest mouseUp handler / switch statement I've ever seeng A few suggestions: I'm not sure if it will make a difference in a mouseUp handler since you're limited by mouse movements, but you might want to lock the screen before and unlock it at the end since you're dealing with field contents directly. This will especially speed up your do command and updating field fRESULT. Also, you spend a lot of effort making sure that DDROP has the correct value, but then you never use it. The switch code is generic, and the DDROP value is used in other objects. I'm sure there's some way to collapse this using a lookup table, but I can't imagine what it would be. That's quite a handler. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
Richmond- Sunday, June 5, 2011, 12:07:00 PM, you wrote: Also, you spend a lot of effort making sure that DDROP has the correct value, but then you never use it. The switch code is generic, and the DDROP value is used in other objects. Took me a couple of times through that to get what you meant. Ah... you mean that same switch code is duplicated in other objects as well. What I'd do in that case is move it out of the objects and make a handler farther along the message path (the stack script, for instance) as command ParseIt switch blahBlahBlah end switch end ParseIt then in the mouseUp handlers just say on mouseUp ... ParseIt ... end mouseUp it's make maintenance much easier and your stack will lose a bit of flabbiness in the process. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: 5000 lines of code
On 06/05/2011 10:33 PM, Mark Wieder wrote: Richmond- Sunday, June 5, 2011, 12:07:00 PM, you wrote: Also, you spend a lot of effort making sure that DDROP has the correct value, but then you never use it. The switch code is generic, and the DDROP value is used in other objects. Took me a couple of times through that to get what you meant. Ah... you mean that same switch code is duplicated in other objects as well. What I'd do in that case is move it out of the objects and make a handler farther along the message path (the stack script, for instance) as command ParseIt switch blahBlahBlah end switch end ParseIt then in the mouseUp handlers just say on mouseUp ... ParseIt ... end mouseUp it's make maintenance much easier and your stack will lose a bit of flabbiness in the process. Thank you very much for such good advice. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
