Re: Mobile Scroller Advice

[Brian Milby via use-livecode]

Thanks to a little off list help from Jacque, I was able to get this
working.  Here's the key piece:

   wait 10 milliseconds -- Panos workaround, bug #18924
   mobileControlSet pName, "hScroll", the hScroll of control pName
   mobileControlSet pName, "vScroll", the vScroll of control pName

The workaround in the bug report actually says wait 0 ms, but I found that
I had to increase it a bit for it to work on my test Pixel (I didn't try to
see how low I could go though).  I'm replying to myself to put the
information out there in case someone is searching the archives.

Thanks all,
Brian

On Wed, Apr 14, 2021 at 12:43 PM Brian Milby  wrote:

> It starts zoomed out with the whole image showing.  A tap will zoom in
> about 25% each time until fully zoomed in (pixel match to display).  The
> idea is that the image will zoom from the center instead of from the
> top/left.  No transition effects are currently used.
>
> At each size, the user can scroll around the entire image.  (It would
> actually be best to zoom around what is currently visible, but that is easy
> once I figure out the other piece.)
>
> The issue is that if viewing a very wide panorama, then jumping to the
> left side isn’t very appealing.
>
> Currently I do delete and recreate the scroller for each zoom, it just
> didn’t work right with the image centered in the group.
>
> Thanks,
> Brian
>
> Sent from my iPhone
>
> > On Apr 14, 2021, at 12:10 PM, J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I'm a little confused. Do you want the zoom to happen within a group
> with a scroller?
> >
> > I've done this a different way. Delete any existing scroller, lock the
> screen, resize the image and its group, unlock the screen with a visual
> effect like zoom in or whatever. Then recreate the scroller at the new
> group size.
> >
> > Is that what you're asking?
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > HyperActive Software | http://www.hyperactivesw.com
> >> On April 13, 2021 10:31:58 PM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Greetings on this lovely Tuesday evening.  I'm in need of a little
> mobile
> >> scroller wisdom.
> >>
> >> I'm working on an app that runs on mobile devices (Apple and Android).
> We
> >> are presenting an image and have enabled the ability for the user to
> tap on
> >> the image to zoom in.  Everything is working except the only way that I
> >> have been able to get the scroller to work reliably is to place the
> image
> >> at the top/left of the group.  What we would really like to do is keep
> the
> >> image centered on the screen as it expands.
> >>
> >> It may be totally obvious, but before I spend a bunch of time throwing
> >> darts and hoping for a bullseye, I thought it would be good to at least
> ask
> >> for a little help.
> >>
> >> Thanks for any assistance you can provide,
> >> Brian
> >> ___
> >> 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
> >
> >
> >
> >
> > ___
> > 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
>
___
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: On the dangers of automated refactoring

[Bob Sneidar via use-livecode]

For my part, I call a function and put the result into a variable. I try not to 
nest fucntions because I cannot easily tell what the result of each function 
is, making it harder to troubleshoot, and also to read my own code! For that 
reason my code is fairly verbose. 

Bob S


> On Apr 14, 2021, at 13:06 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Me:
> 
> >> The biggest code is the most repetitive and least modular!
> 
> Jacqueline:
> 
> > Not always, but often. I try to aim for the smallest code base,
> > so I think the contest should be to solve a complex problem
> > with the least amount of code.
> 
> Yes, but not brevity for its own sake! Rather for maintainability,
> efficiency, and to avoid the code-org messes that people try to
> refactor their way out of after practicing bad habits.
> 
> The optimal balance of brevity with performance, readability, and 
> maintainability is where we'll find the best code!
> 
> That'll be fairly tight code, but not always the very smallest.
> I do love concise code; I've seen some whopping humongous scripts! :)
> 
> Best wishes,
> 
> Curry Kenworthy
> 
> Custom Software Development
> "Better Methods, Better Results"
> LiveCode Training and Consulting
> http://livecodeconsulting.com/


___
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: Windows 64 bit LC Still slow

[Bob Sneidar via use-livecode]

I think we can eliminate the BITNESS (stupid spell correct)

Bob S


> On Apr 14, 2021, at 12:54 , Bob Sneidar via use-livecode 
>  wrote:
> 
>  I think we can eliminate the witness as a possible cause


___
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: On the dangers of automated refactoring

[Alex Tweedly via use-livecode]

On 14/04/2021 21:01, Ralph DiMola via use-livecode wrote:

Good question... I'm thinking it's the same reason that with strict compilation 
enabled a variable in a repeat loop does not have to be declared as a script 
local. If it is declared as a script local no shadow error occurs. A handler 
parameter in a way is the same as it doesn't need parameters to be declared.

What is the scope of the variable vs. the handler parameter when the handler is 
running? That's bigger question.


The parameter is different from the script-local variable (i.e. changing 
it within the handler changes the parameter, not the script-local).


(and, btw, the same non-reporting happens if it's a global shadowed by a 
parameter name).


Alex.




___
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: On the dangers of automated refactoring

[Curry Kenworthy via use-livecode]

Me:

>> The biggest code is the most repetitive and least modular!

Jacqueline:

> Not always, but often. I try to aim for the smallest code base,
> so I think the contest should be to solve a complex problem
> with the least amount of code.

Yes, but not brevity for its own sake! Rather for maintainability,
efficiency, and to avoid the code-org messes that people try to
refactor their way out of after practicing bad habits.

The optimal balance of brevity with performance, readability, and 
maintainability is where we'll find the best code!


That'll be fairly tight code, but not always the very smallest.
I do love concise code; I've seen some whopping humongous scripts! :)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
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: On the dangers of automated refactoring

[Ralph DiMola via use-livecode]

Good question... I'm thinking it's the same reason that with strict compilation 
enabled a variable in a repeat loop does not have to be declared as a script 
local. If it is declared as a script local no shadow error occurs. A handler 
parameter in a way is the same as it doesn't need parameters to be declared.

What is the scope of the variable vs. the handler parameter when the handler is 
running? That's bigger question.

 
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Alex Tweedly via use-livecode
Sent: Wednesday, April 14, 2021 3:39 PM
To: use-livecode@lists.runrev.com
Cc: Alex Tweedly
Subject: Re: On the dangers of automated refactoring


On 14/04/2021 10:23, Andre Garzia via use-livecode wrote:
> That is the main issue, the code was using the wrong hungarian-lite 
> prefixes. You’d see something like
>
>on myHandler pDataA
>  …
>end myHandler
>
>
> But, lo and behold, on top of the script there would be something like
>
>local pDataA
>
> Now, is that an argument to a handler? a script-local? It depends! Strict 
> compilation mode doesn’t care about variable shadowing.

Never mind strict compilation mode, I think this should be a "compile" 
error anyway.

With or without strict-compilation :

   variable shadowing with a script-local and a handler-local is an error.

   variable shadowing with a parameter and a handler-local is an error.

why on earth is variable shadowing between a script-local and a parameter not 
also an error.

Alex.


___
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


___
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: Windows 64 bit LC Still slow

[Bob Sneidar via use-livecode]

32 bit programs running under a 64 bit OS have to run through an “emulator” 
(that is probably not the right term for it). I was simply saying that I think 
we can eliminate the witness as a possible cause for why Windows standalone and 
the IDE run so much slower than on MacOS or Linux. 

Bob S


> On Apr 14, 2021, at 12:15 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Just an update to a prior thread (which I cannot seem to find), LC for 
> Windows 64 bit version is just as slow at accessing databases (and I will 
> assume saving files) as the 32 bit version. I had previously brain farted and 
> tested with the 32 bit version, but as far as I can tell there is not 
> improvement in performance with 64 bit. 
> 
> Bob S
> 
> 
> ___
> 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

___
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: On the dangers of automated refactoring

[Alex Tweedly via use-livecode]

On 14/04/2021 10:23, Andre Garzia via use-livecode wrote:

That is the main issue, the code was using the wrong hungarian-lite prefixes. 
You’d see something like

   on myHandler pDataA
 …
   end myHandler


But, lo and behold, on top of the script there would be something like

   local pDataA

Now, is that an argument to a handler? a script-local? It depends! Strict 
compilation mode doesn’t care about variable shadowing.


Never mind strict compilation mode, I think this should be a "compile" 
error anyway.


With or without strict-compilation :

  variable shadowing with a script-local and a handler-local is an error.

  variable shadowing with a parameter and a handler-local is an error.

why on earth is variable shadowing between a script-local and a 
parameter not also an error.


Alex.


___
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: Windows 64 bit LC Still slow

[matthias rebbe via use-livecode]

Should 64-bit programs be faster?

I thought the advantage of 64bit programs is that they can access more memory 
(more than 3GB) and that they can perform 64-bit register operations, whatever 
that is. ;)




Matthias Rebbe
-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 14.04.2021 um 21:15 schrieb Bob Sneidar via use-livecode 
> :
> 
> Just an update to a prior thread (which I cannot seem to find), LC for 
> Windows 64 bit version is just as slow at accessing databases (and I will 
> assume saving files) as the 32 bit version. I had previously brain farted and 
> tested with the 32 bit version, but as far as I can tell there is not 
> improvement in performance with 64 bit. 
> 
> Bob S
> 
> 
> ___
> 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


___
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

Windows 64 bit LC Still slow

[Bob Sneidar via use-livecode]

Just an update to a prior thread (which I cannot seem to find), LC for Windows 
64 bit version is just as slow at accessing databases (and I will assume saving 
files) as the 32 bit version. I had previously brain farted and tested with the 
32 bit version, but as far as I can tell there is not improvement in 
performance with 64 bit. 

Bob S


___
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: On the dangers of automated refactoring

[J. Landman Gay via use-livecode]

On 4/13/21 4:07 PM, Curry Kenworthy via use-livecode wrote:


The biggest code is the most repetitive and least modular!


Not always, but often. I try to aim for the smallest code base, so I think the contest should 
be to solve a complex problem with the least amount of code.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: How do I change the textcolor of the selected text in a native iOS field?

[William de Smet via use-livecode]

Thanks for pointing me to "selectedRange".

put mobileControlGet ("field1", "selectedRange") into myTest
-- answer myTest  //gives range 1,5
mobileControlSet "field1", "textColor", "255,0,0"

This doesn't work because all text will be colored and not just the
selectedRange.


greetings,

William




Op di 13 apr. 2021 om 21:11 schreef J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com>:

> On 4/13/21 6:15 AM, William de Smet via use-livecode wrote:
> > Hi there,
> >
> > How do I get the selectedText of a native iOS field?
> > I want to change the color of the text selection in the field.
>
> I think you want "selectedRange" which returns the start index and the
> length of the text
> selected. Judging from the dictionary it looks like it only works on
> multiline fields.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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
>
___
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: Mobile Scroller Advice

[Brian Milby via use-livecode]

It starts zoomed out with the whole image showing.  A tap will zoom in about 
25% each time until fully zoomed in (pixel match to display).  The idea is that 
the image will zoom from the center instead of from the top/left.  No 
transition effects are currently used.

At each size, the user can scroll around the entire image.  (It would actually 
be best to zoom around what is currently visible, but that is easy once I 
figure out the other piece.)

The issue is that if viewing a very wide panorama, then jumping to the left 
side isn’t very appealing.

Currently I do delete and recreate the scroller for each zoom, it just didn’t 
work right with the image centered in the group.

Thanks,
Brian

Sent from my iPhone

> On Apr 14, 2021, at 12:10 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm a little confused. Do you want the zoom to happen within a group with a 
> scroller?
> 
> I've done this a different way. Delete any existing scroller, lock the 
> screen, resize the image and its group, unlock the screen with a visual 
> effect like zoom in or whatever. Then recreate the scroller at the new group 
> size.
> 
> Is that what you're asking?
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>> On April 13, 2021 10:31:58 PM Brian Milby via use-livecode 
>>  wrote:
>> 
>> Greetings on this lovely Tuesday evening.  I'm in need of a little mobile
>> scroller wisdom.
>> 
>> I'm working on an app that runs on mobile devices (Apple and Android).  We
>> are presenting an image and have enabled the ability for the user to tap on
>> the image to zoom in.  Everything is working except the only way that I
>> have been able to get the scroller to work reliably is to place the image
>> at the top/left of the group.  What we would really like to do is keep the
>> image centered on the screen as it expands.
>> 
>> It may be totally obvious, but before I spend a bunch of time throwing
>> darts and hoping for a bullseye, I thought it would be good to at least ask
>> for a little help.
>> 
>> Thanks for any assistance you can provide,
>> Brian
>> ___
>> 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
> 
> 
> 
> 
> ___
> 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

___
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: Mobile Scroller Advice

[J. Landman Gay via use-livecode]

I'm a little confused. Do you want the zoom to happen within a group with a 
scroller?


I've done this a different way. Delete any existing scroller, lock the 
screen, resize the image and its group, unlock the screen with a visual 
effect like zoom in or whatever. Then recreate the scroller at the new 
group size.


Is that what you're asking?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 13, 2021 10:31:58 PM Brian Milby via use-livecode 
 wrote:



Greetings on this lovely Tuesday evening.  I'm in need of a little mobile
scroller wisdom.

I'm working on an app that runs on mobile devices (Apple and Android).  We
are presenting an image and have enabled the ability for the user to tap on
the image to zoom in.  Everything is working except the only way that I
have been able to get the scroller to work reliably is to place the image
at the top/left of the group.  What we would really like to do is keep the
image centered on the screen as it expands.

It may be totally obvious, but before I spend a bunch of time throwing
darts and hoping for a bullseye, I thought it would be good to at least ask
for a little help.

Thanks for any assistance you can provide,
Brian
___
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





___
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

[ANN] Release 9.6.2 RC-5

[panagiotis merakos via use-livecode]

Dear list members,

We are pleased to announce the release of LiveCode 9.6.2 RC-5.


Getting the Release
===
You can get the release at https://downloads.livecode.com/livecode/ or via
the automatic updater.


Release Contents

LiveCode 9.6.2 RC-5 comes with 2 regression fixes:

- revUpdateGeometry in resizeStack handler causes a lock up when
maximizing/unmaximizing stack on Big Sur
- Script Editor not resizable - it is freezing up on Big Sur

For the full list of all fixes, updates and enhancements please see the
release notes:

http://downloads.livecode.com/livecode/9_6_2/LiveCodeNotes-9_6_2_rc_5.pdf


Known issues

- The Browser widget's native layer is not shown in some Linux distros with
Cinnamon window manager.
- The use of the Browser widget is not supported on Ubuntu 18.04 64 bit LTS
yet.


Required Software
=
To build iOS apps with LiveCode you must have the appropriate versions of
Xcode as follows:

  - macOS 10.13.4: Xcode 10.1 - LiveCode builds iOS apps using the iOS 12.1
SDK
  - macOS 10.14.4: Xcode 11.3.x - LiveCode builds iOS apps using the iOS
13.2 SDK
  - macOS 10.15.4+: Xcode 12.1.x - LiveCode builds iOS apps using the iOS
14.1 SDK

There is a full list of working LiveCode/macOS/Xcode combinations here:
https://livecode.com/docs/9-5-0/faq/faq/

Note: Whilst we endeavour to release updated versions of LiveCode
supporting the latest Xcode/iOS SDKs as quickly as possible; we strongly
recommend disabling automatic update of Xcode or downloading the specific
version of Xcode required directly from the Apple developer portal and
installing it separately.

Important: From the end of June 2020, Apple is only accepting apps built
using iOS13 SDKs. This means that, if you wish to submit apps to the
AppStore you will have to be running at least macOS 10.14 in order to be
able to install the necessary version of Xcode.


Feedback

Please report any bugs encountered on our quality center at
http://quality.livecode.com/

We have a forum available for discussing LiveCode Builder at
http://forums.livecode.com/viewforum.php?f=93


Have fun!
The LiveCode Team
--
___
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

revBrowserNavigate

[jbv via use-livecode]

Hi list,
I am using revBrowserNavigate and have the following problem :
sometimes some urls won't display, but they display fine when
I enter them in the address bar of the browser.
What am I missing and what should I check ?
I am using LC Community 8.1.10.

Thanks in advance. Best,
jbv

___
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: On the dangers of automated refactoring

[Peter W A Wood via use-livecode]

Thanks Andre

I enjoyed putting the library together though at the time unit testing and 
LiveCode just don’t go together. Personally I find developing with tests gives 
me peace of mind about my code. 

As for refactoring, normally defined as the process of improving code without 
changing it’s behaviour, having a set of tests make it so much more productive.

LiveCode provides a really great platform for unit testing. The language makes 
it so much more simple to write unit tests of GUIs than any other language that 
I know. Even my small testing library could drive a GUI script.

I don’t spend much time with LiveCode these days. I always wanted to explore 
the multimedia capabilities of LiveCode which seem to surfing off into the 
ether. I never really put the time into getting on top of the multimedia 
aspects of LiveCode and, in all probability, lack the creativity to build 
anything of note.

PS Red Lang is going slowly. I haven’t been involved for a while. It’s mainly 
legacy Rebol, JavaScript, a little Lua and more JavaScript work for me these 
days.

> On 13 Apr 2021, at 19:10, Andre Garzia via use-livecode 
>  wrote:
> 
> Peter,
> 
> This is neat!
> 
> I also have a small test library, but mine is way less complete than yours. I 
> never released it because it was quite incomplete.
> 
> Maybe writing a tutorial or doing a small screencast showing it working might 
> help people understand why it is important. I bet many here never used a unit 
> testing library.
> 
> PS: How’s Red Lang going? :D
> 
>> On 13 Apr 2021, at 12:02, Peter W A Wood via use-livecode 
>>  wrote:
>> 
>> Hi Andre
>> 
>>> On 13 Apr 2021, at 18:05, Andre Garzia via use-livecode 
>>>  wrote:
>>> 
>>> We don’t even have unit testing libraries so that we can make sure our code 
>>> works as expected.
>> 
>> I published a simple unit testing library on GitHub but it din’t get any 
>> traction - https://github.com/PeterWAWood/LiveCode-MiniTest 
>> 
>> 
>> Peter
>> 
>> ___
>> 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
> 
> 
> ___
> 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


___
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: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

That is the main issue, the code was using the wrong hungarian-lite prefixes. 
You’d see something like

  on myHandler pDataA
…
  end myHandler


But, lo and behold, on top of the script there would be something like

  local pDataA

Now, is that an argument to a handler? a script-local? It depends! Strict 
compilation mode doesn’t care about variable shadowing.

> On 13 Apr 2021, at 17:48, Richard Gaskin via use-livecode 
>  wrote:
> 
> Andre Garzia wrote:
> 
> > What I didn’t realise was that there was variable shadowing happening
> > in which handler arguments were named with the same name as script-
> > local variables, my smart replacing removed those arguments because
> > there was no need to redeclare the script-local vars. I didn’t realise
> > at that time, that those variables were real arguments being passed to
> > the handlers, they just happened to have the same name as script-local
> > vars in the same script and were in fact shadowing them.
> 
> Is this a case where "Strict Compilation Mode" or Hungarian-lite* notation 
> may have been useful?
> 
> 
> * http://www.fourthworld.com/embassy/articles/scriptstyle.html
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> 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


___
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: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

Safety boots are a must for developing safe code.

> On 13 Apr 2021, at 16:48, Bob Sneidar via use-livecode 
>  wrote:
> 
> It's nothing short of a miracle that the shot didn't go INTO your foot. :-) 
> 
> Bob S
> 
> 
>> On Apr 13, 2021, at 03:05 , Andre Garzia via use-livecode 
>>  wrote:
>> 
>> Let me tell you folks a recent story in which I tried to do exactly that and 
>> shot myself on the foot.
> 
> 
> ___
> 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


___
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: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

> On 13 Apr 2021, at 16:28, Mark Wieder via use-livecode 
>  wrote:
> 
> Ouch. Don't do that.

I agree, that was not my decision. I maintaining this code but I’m not the 
original developer.
___
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