Re: Offtopic: Can anybody create a small DLL for me?

[Bob Sneidar via use-livecode]

Plus sudo will require authentication, yes? That would not be automated. The 
purpose of my function is to be able to detect the default adapter and compare 
it to a stored last known adapter to see if it has changed. If it has, I have 
my app re-authenticate.

Bob S


On Apr 13, 2021, at 9:06 PM, Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

How do you tell which is the default adapter?

Bob S


On Apr 13, 2021, at 8:00 PM, Mark Wieder via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On linux it's very easy

sudo arp-scan -l

will give you a nice sorted list.

--
Mark Wieder
ahsoftw...@gmail.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: Offtopic: Can anybody create a small DLL for me?

[Bob Sneidar via use-livecode]

How do you tell which is the default adapter?

Bob S


> On Apr 13, 2021, at 8:00 PM, Mark Wieder via use-livecode 
>  wrote:
> 
> On linux it's very easy
> 
> sudo arp-scan -l
> 
> will give you a nice sorted list.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.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

Mobile Scroller Advice

[Brian Milby via use-livecode]

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

Re: Offtopic: Can anybody create a small DLL for me?

[Mark Wieder via use-livecode]

On linux it's very easy

sudo arp-scan -l

will give you a nice sorted list.

--
 Mark Wieder
 ahsoftw...@gmail.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: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

I tried that but I don't keep Xcode in the root of the Applications folder 
and the stack gave a warning. When I moved it there, the Xcode commands 
couldn't find it because I'd set the Xcode default to a copy in a subfolder.


Maybe a future update can determine the user's Xcode location. I have three 
copies because different versions of LC require different versions of Xcode.



What took the most time was figuring out what was wrong.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 13, 2021 6:26:02 PM matthias rebbe via use-livecode 
 wrote:


Couldn't you search for the ASC provider in the helper stack pressing the 
"Loupe" icon in the general settings?



-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 14.04.2021 um 01:12 schrieb J. Landman Gay via use-livecode 
:


Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use 
it frequently.


I probably will continue with the manual method for a while though, since I 
have three different apps to notarize and I have to update the General 
settings each time. Maybe later I'll revise your script to fill in the data 
for me.


What I did not realize until I wasted a lot of time today is that the ASC 
changes depending on the app password, the ID Application, or something 
else I can't identify. It kept telling me I wasn't a member of my own 
developer account. I finally ran the Terminal command that returns all the 
ASCs and my ASC was different than it was before.


People who are a member of only one account won't have that problem, but it 
took me a long time to figure out what was wrong. Once I had the right ASC 
your helper did its work gracefully.



On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you 
add the below code  to your stack script
then you can directly code sign and notarize the created macOS standalone 
right after it was built. ;)

on standaloneSaved pFolderSavedIn
if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true
then
answer "Do you want to notarize?" with "yes" or "No"
if it ="yes"
then
put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
stack & ".app" into tAppBundle

notarizeApp tAppbundle
else
put "Don't notarize"
end if
end if
pass standalonesaved
end standaloneSaved
on notarizeApp tAppbundle
 put "Now notarizing..."   after message
 ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"
put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"
set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
"Codesign App, create & codesign DMG, then notarize DMG and staple DMG and App"
set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" 
to false
send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 
5 seconds

end notarizeApp
-
Matthias Rebbe
Life Is Too Short For Boring Code
Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
:


On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:


On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle 
notarisation on the mac out-of-the-box.

Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
process much easier. Fill out some info, click a button, and your 
notarization request is sent to Apple, returned, and stapled to your app.


It's an extra step which I think LC should incorporate, but for now it 
saves quite a bit of work. You can find it at this LC lesson, which 
includes all the manual steps if you want to do it that way, but at the 
bottom describes his automated tool as well. You can download the stack 
from the link at the top of the lesson.




I've used it on more than one Mac app and it works. The hardest part is 
dealing with Apple and of course there's no help for that.


--
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 

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[matthias rebbe via use-livecode]

Couldn't you search for the ASC provider in the helper stack pressing the 
"Loupe" icon in the general settings?


-
Matthias Rebbe
Life Is Too Short For Boring Code


> Am 14.04.2021 um 01:12 schrieb J. Landman Gay via use-livecode 
> :
> 
> Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use 
> it frequently.
> 
> I probably will continue with the manual method for a while though, since I 
> have three different apps to notarize and I have to update the General 
> settings each time. Maybe later I'll revise your script to fill in the data 
> for me.
> 
> What I did not realize until I wasted a lot of time today is that the ASC 
> changes depending on the app password, the ID Application, or something else 
> I can't identify. It kept telling me I wasn't a member of my own developer 
> account. I finally ran the Terminal command that returns all the ASCs and my 
> ASC was different than it was before.
> 
> People who are a member of only one account won't have that problem, but it 
> took me a long time to figure out what was wrong. Once I had the right ASC 
> your helper did its work gracefully.
> 
> 
> On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:
>> Jacque,
>> and if put the that NotarizerHelperStack into the plugins folder and if you 
>> add the below code  to your stack script
>> then you can directly code sign and notarize the created macOS standalone 
>> right after it was built. ;)
>> on standaloneSaved pFolderSavedIn
>> if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true
>> then
>> answer "Do you want to notarize?" with "yes" or "No"
>> if it ="yes"
>> then
>> put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
>> stack & ".app" into tAppBundle
>> notarizeApp tAppbundle
>> else
>> put "Don't notarize"
>> end if
>> end if
>> pass standalonesaved
>> end standaloneSaved
>> on notarizeApp tAppbundle
>>  put "Now notarizing..."   after message
>>  ##path to the notarizer Stack..
>> ## either use an absolute path
>> --go stack "/Users/matthias/Dropbox/My 
>> Livecode/Plugins/mrSignNotarizeHelperV2.livecode"
>> ##or if the helper stack is in the plugins folder
>> go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"
>> put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"
>> set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
>> "Codesign App, create & codesign DMG, then notarize DMG and staple DMG and 
>> App"
>> set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" 
>> to false
>> send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
>> seconds
>> end notarizeApp
>> -
>> Matthias Rebbe
>> Life Is Too Short For Boring Code
>>> Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
>>> :
>>> 
>>> On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
> On 13 Apr 2021, at 11:28, Andre Garzia via 
> use-livecode  wrote:
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.
 Oh boy, THIS!
>>> 
>>> +1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
>>> process much easier. Fill out some info, click a button, and your 
>>> notarization request is sent to Apple, returned, and stapled to your app.
>>> 
>>> It's an extra step which I think LC should incorporate, but for now it 
>>> saves quite a bit of work. You can find it at this LC lesson, which 
>>> includes all the manual steps if you want to do it that way, but at the 
>>> bottom describes his automated tool as well. You can download the stack 
>>> from the link at the top of the lesson.
>>> 
>>> 
>>> 
>>> I've used it on more than one Mac app and it works. The hardest part is 
>>> dealing with Apple and of course there's no help for that.
>>> 
>>> -- 
>>> 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
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode 

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

Cool. Thanks. I do keep NotarizationHelper in my plugins folder since I use it 
frequently.

I probably will continue with the manual method for a while though, since I have three 
different apps to notarize and I have to update the General settings each time. Maybe later 
I'll revise your script to fill in the data for me.


What I did not realize until I wasted a lot of time today is that the ASC changes depending on 
the app password, the ID Application, or something else I can't identify. It kept telling me I 
wasn't a member of my own developer account. I finally ran the Terminal command that returns 
all the ASCs and my ASC was different than it was before.


People who are a member of only one account won't have that problem, but it took me a long time 
to figure out what was wrong. Once I had the right ASC your helper did its work gracefully.



On 4/13/21 2:17 PM, matthias rebbe via use-livecode wrote:

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you add 
the below code  to your stack script
then you can directly code sign and notarize the created macOS standalone right 
after it was built. ;)

on standaloneSaved pFolderSavedIn

if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true

then

answer "Do you want to notarize?" with "yes" or "No"

if it ="yes"

then

put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this stack & 
".app" into tAppBundle

notarizeApp tAppbundle

else

put "Don't notarize"

end if

end if

pass standalonesaved

end standaloneSaved


on notarizeApp tAppbundle
  put "Now notarizing..."   after message

  ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"

put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"

set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to "Codesign 
App, create & codesign DMG, then notarize DMG and staple DMG and App"

set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" to 
false

send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
seconds

end notarizeApp



-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
:

On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:

On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.

Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
process much easier. Fill out some info, click a button, and your notarization 
request is sent to Apple, returned, and stapled to your app.

It's an extra step which I think LC should incorporate, but for now it saves 
quite a bit of work. You can find it at this LC lesson, which includes all the 
manual steps if you want to do it that way, but at the bottom describes his 
automated tool as well. You can download the stack from the link at the top of 
the lesson.



I've used it on more than one Mac app and it works. The hardest part is dealing 
with Apple and of course there's no help for that.

--
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




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

[Curry Kenworthy via use-livecode]

Andre:

> Often in LiveCode (and most programming languages to be honest)
> we go coding for a long while and then realise that our code
> need extensive refactoring. We may have repeated a pattern over
> and over again and discovered that we need to change every
> instance of them, or something similar.

Speaking to LC users as a whole rather than Andre in particular,
tools to help with smart refactoring are useful. It all helps.
But there's an even bigger danger than the one already described:

Relying on tech to substitute for good fundamental coding skills.
If a script needs many repeated changes to fix a single problem,
usually that's because the code was not well-organized and modular.

With good coding habits, you will excel with or without such tools.
And when used carefully, they can increase your productivity.
But if you have powerful tools with bad habits, you'll have trouble.

Look at the F-35 stealth fighter, for example. Used in many nations.
Agile coding is a key enabler in the project, but bugs are a problem.
They've had cost increases and delays. Efficient coding is crucial.
Whether jets or vaccines, many lives actually depend on computer code.

In other words, good coding habits are more important than ever.
Software will win or lose wars and determine health outcomes.
You may not be in those line of work, but good habits save headaches!

Well-designed code is a joy to maintain. One problem = one change.
Modular, so that we're not repeating the same code with tiny variations.
There will be cases where old code needs a revision, but much easier.

Bob:

> We should have a contest: Who has the biggest code base.
> Mine's pretty big, but I doubt it's the biggest. :-)

The biggest code is the most repetitive and least modular!
I've seen scripts that were long enough to overwhelm the SE,
yet performed fairly simple tasks. Could be 1/10 the code.

Good topic. Back to work

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

[Paul Dupuis via use-livecode]

On 4/13/2021 2:39 PM, Mark Wieder via use-livecode wrote:

On 4/13/21 8:37 AM, Paul Dupuis via use-livecode wrote:
I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would 
like to see better integrated into the IDE.


Paul - thanks for the kind words there.
I took most of your advice and updated the latest build to both github 
and the LiveCodeShare/Online/Sample Stacks... whatever that thing's 
called.


There's now a busy cursor for the Find Orphans feature since it's 
nested repeat loops, and there's a menu item added to the Help menu 
with some minimal help text to jog your memory. I did stop short of 
making it a new menu (vs menuItem)... I think it's more properly a 
subset of the Edit functions, but if you want to play around with it I 
think you'd have to modify the revMenuBar stack. Open to any other 
suggestions.


And it's MIT-licensed, by the way, so anyone can feel free to do what 
they want with it.


https://github.com/mwieder/revRefactor



Wow! Thanks! A terrific tool by the way - and not to deprive any of the 
huge credit you deserve, but features such as your tool are things I 
would expect from the IDE of a "business" edition of LC, hence my 
thought LC, LTD make an arrangement with you to include it in the IDE as 
shipped.



___
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

[Paul Dupuis via use-livecode]

On 4/13/2021 12:06 PM, Bob Sneidar via use-livecode wrote:

How do you find that? Github?


Don't remember how I found it - I think an announcement by Mark to the 
list, but, yup, Github:


https://github.com/mwieder/revRefactor

___
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[matthias rebbe via use-livecode]

Jacque,
and if put the that NotarizerHelperStack into the plugins folder and if you add 
the below code  to your stack script 
then you can directly code sign and notarize the created macOS standalone right 
after it was built. ;)

on standaloneSaved pFolderSavedIn

if the cRevStandaloneSettings["MacOSX x86-64"] of this stack is true

then

answer "Do you want to notarize?" with "yes" or "No"

if it ="yes"

then

put pFolderSavedIN & "MacOSX/" & the cRevStandaloneSettings["name"] of this 
stack & ".app" into tAppBundle

notarizeApp tAppbundle

else

put "Don't notarize"

end if

end if

pass standalonesaved

end standaloneSaved


on notarizeApp tAppbundle
 put "Now notarizing..."   after message

 ##path to the notarizer Stack..
## either use an absolute path
--go stack "/Users/matthias/Dropbox/My 
Livecode/Plugins/mrSignNotarizeHelperV2.livecode"

##or if the helper stack is in the plugins folder
go stack revEnvironmentUserPluginsPath()&"/mrSignNotarizeHelperV2.livecode"

put tAppbundle into fld "appbundle" of cd 1 of stack "mrSignNotarizeHelperV2"

set the label of btn "action" of cd 1 of stack "mrSignNotarizeHelperV2" to 
"Codesign App, create & codesign DMG, then notarize DMG and staple DMG and App"

set the hilite of btn "debugmode" of cd 1 of stack "mrSignNotarizeHelperV2" to 
false

send "mouseup" to btn "start" of cd 1 of stack "mrSignNotarizeHelperV2" in 5 
seconds

end notarizeApp



-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 13.04.2021 um 21:03 schrieb J. Landman Gay via use-livecode 
> :
> 
> On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:
>>> On 13 Apr 2021, at 11:28, Andre Garzia via 
>>> use-livecode  wrote:
>>> 
>>> On the other hand, I think that the SB should create standalones that can 
>>> actually be deployed, this means that it should be able to handle 
>>> notarisation on the mac out-of-the-box.
>> Oh boy, THIS!
> 
> +1. But for now I use Matthias' mrSignNotarize helper tool which makes the 
> process much easier. Fill out some info, click a button, and your 
> notarization request is sent to Apple, returned, and stapled to your app.
> 
> It's an extra step which I think LC should incorporate, but for now it saves 
> quite a bit of work. You can find it at this LC lesson, which includes all 
> the manual steps if you want to do it that way, but at the bottom describes 
> his automated tool as well. You can download the stack from the link at the 
> top of the lesson.
> 
> 
> 
> I've used it on more than one Mac app and it works. The hardest part is 
> dealing with Apple and of course there's no help for that.
> 
> -- 
> 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: How do I change the textcolor of the selected text in a native iOS field?

[J. Landman Gay via use-livecode]

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

Re: [ANN] Release 9.6.2 RC-4

[JeeJeeStudio via use-livecode]

Many thanks mark for explaining.
So the IDE is a real 32 bit or a real 64bit application.
Am I understanding it correct that it is the same for the executable an LC
user/devbuilds for Windows? the build of a stack is a real 64bit?

Op di 13 apr. 2021 om 18:09 schreef Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com>:

> On 2021-04-13 16:46, Bob Sneidar via use-livecode wrote:
> > Hi Mark.
> >
> > I downloaded LC 9.6.2 for Windows and installed it on a Server 2012
> > VM. It installed in the Program Files (x86) folder. I was under the
> > impression that only happens when the app is a 32 bit app.
>
> Then you downloaded the 32-bit installer.
>
> > Are you implying the standalones are 64 bit but the LC app is 32? If
> > that were the case, then no benchmarks done in the IDE would be valid.
> > But it's more likely I am misinformed.
>
> Both 32-bit and 64-bit Windows IDEs can build 32-bit and/or 64-bit
> windows standalones - you can choose in the standalone builder.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[J. Landman Gay via use-livecode]

On 4/13/21 10:43 AM, Keith Martin via use-livecode wrote:

On 13 Apr 2021, at 11:28, Andre Garzia via 
use-livecode  wrote:

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.


Oh boy, THIS!


+1. But for now I use Matthias' mrSignNotarize helper tool which makes the process much easier. 
Fill out some info, click a button, and your notarization request is sent to Apple, returned, 
and stapled to your app.


It's an extra step which I think LC should incorporate, but for now it saves quite a bit of 
work. You can find it at this LC lesson, which includes all the manual steps if you want to do 
it that way, but at the bottom describes his automated tool as well. You can download the stack 
from the link at the top of the lesson.




I've used it on more than one Mac app and it works. The hardest part is dealing with Apple and 
of course there's no help for that.


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

[Mark Wieder via use-livecode]

On 4/13/21 9:48 AM, 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



Yep.
But knowing Andre I'll bet he didn't write the original code, just had 
the good fortune to inherit it. 


--
 Mark Wieder
 ahsoftw...@gmail.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

[Mark Wieder via use-livecode]

On 4/13/21 8:37 AM, Paul Dupuis via use-livecode wrote:
I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would like 
to see better integrated into the IDE.


Paul - thanks for the kind words there.
I took most of your advice and updated the latest build to both github 
and the LiveCodeShare/Online/Sample Stacks... whatever that thing's called.


There's now a busy cursor for the Find Orphans feature since it's nested 
repeat loops, and there's a menu item added to the Help menu with some 
minimal help text to jog your memory. I did stop short of making it a 
new menu (vs menuItem)... I think it's more properly a subset of the 
Edit functions, but if you want to play around with it I think you'd 
have to modify the revMenuBar stack. Open to any other suggestions.


And it's MIT-licensed, by the way, so anyone can feel free to do what 
they want with it.


https://github.com/mwieder/revRefactor

--
 Mark Wieder
 ahsoftw...@gmail.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

[Brian Milby via use-livecode]

It was actually more the mis-application of Hungarian-lite.  I think it 
compiled with strict enabled.

Sent from my iPhone

> On Apr 13, 2021, at 12:50 PM, 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

[Richard Gaskin via use-livecode]

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

RE: [ANN] Release 9.6.2 RC-4

[chipsm themartinz.com via use-livecode]

Hi everyone. I am totally confused by this topic.
I know that I downloaded the LC 9.6.2 RC4 64 bit windows version and Windows 10 
,latest update, refuses to run the installer.
I have been watching the list and decided to just wait and see if there would 
be a fix for this. I have turned off my McAfee to see if that would help, but 
to no avail. I have also tried to install the program using the administrator 
option.
Is there any recommendations for a solution to this problem? Is this the 
problem that everyone is Listing about?

Sincerely,

Clarence Martin
Email: chi...@themartinz.com
Phone: 626 6965561

-Original Message-
From: use-livecode  On Behalf Of Mark 
Waddingham via use-livecode
Sent: Tuesday, April 13, 2021 9:09 AM
To: How to use LiveCode 
Cc: Mark Waddingham 
Subject: Re: [ANN] Release 9.6.2 RC-4

On 2021-04-13 16:46, Bob Sneidar via use-livecode wrote:
> Hi Mark.
> 
> I downloaded LC 9.6.2 for Windows and installed it on a Server 2012 
> VM. It installed in the Program Files (x86) folder. I was under the 
> impression that only happens when the app is a 32 bit app.

Then you downloaded the 32-bit installer.

> Are you implying the standalones are 64 bit but the LC app is 32? If 
> that were the case, then no benchmarks done in the IDE would be valid.
> But it's more likely I am misinformed.

Both 32-bit and 64-bit Windows IDEs can build 32-bit and/or 64-bit windows 
standalones - you can choose in the standalone builder.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: [ANN] Release 9.6.2 RC-4

[Mark Waddingham via use-livecode]

On 2021-04-13 16:46, Bob Sneidar via use-livecode wrote:

Hi Mark.

I downloaded LC 9.6.2 for Windows and installed it on a Server 2012
VM. It installed in the Program Files (x86) folder. I was under the
impression that only happens when the app is a 32 bit app.


Then you downloaded the 32-bit installer.


Are you implying the standalones are 64 bit but the LC app is 32? If
that were the case, then no benchmarks done in the IDE would be valid.
But it's more likely I am misinformed.


Both 32-bit and 64-bit Windows IDEs can build 32-bit and/or 64-bit 
windows standalones - you can choose in the standalone builder.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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]

How do you find that? Github? 

Bob S


> On Apr 13, 2021, at 08:59 , Paul Dupuis via use-livecode 
>  wrote:
> 
> On 4/13/2021 11:52 AM, Bob Sneidar via use-livecode wrote:
>> We should have a contest: Who has the biggest code base. Mine's pretty big, 
>> but I doubt it's the biggest.:-)
>> 
> ~ 83,000 lines of Livecode script, not counting 3rd party library stacks 
> (Wordlib, Spreadlib, lclSpell, ChartMaker) and some custom externals.
> 
> 
> ___
> 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

[Paul Dupuis via use-livecode]

On 4/13/2021 11:52 AM, Bob Sneidar via use-livecode wrote:

We should have a contest: Who has the biggest code base. Mine's pretty big, but 
I doubt it's the biggest.:-)

~ 83,000 lines of Livecode script, not counting 3rd party library stacks 
(Wordlib, Spreadlib, lclSpell, ChartMaker) and some custom externals.



___
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]

We should have a contest: Who has the biggest code base. Mine's pretty big, but 
I doubt it's the biggest. :-)

Bob S


> On Apr 13, 2021, at 03:48 , David Bovill via use-livecode 
>  wrote:
> 
> I’d be interested to understand the nature of the gazillion stack project to 
> see how it compares to my gazillion stack project (and I presume others). We 
> could learn things by comparing approaches.

___
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]

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

Re: [ANN] Release 9.6.2 RC-4

[Bob Sneidar via use-livecode]

Hi Mark. 

I downloaded LC 9.6.2 for Windows and installed it on a Server 2012 VM. It 
installed in the Program Files (x86) folder. I was under the impression that 
only happens when the app is a 32 bit app. 

Are you implying the standalones are 64 bit but the LC app is 32? If that were 
the case, then no benchmarks done in the IDE would be valid. But it's more 
likely I am misinformed. 

Bob S


> On Apr 13, 2021, at 08:19 , Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-04-13 16:15, Mark Wieder via use-livecode wrote:
>> Do the release notes need updating?
> 
> Hah! Yes - we've had a 64-bit windows build (separate installer) available 
> since 9.5.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


___
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Keith Martin via use-livecode]

> On 13 Apr 2021, at 11:28, Andre Garzia via use-livecode 
>  wrote:
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.


Oh boy, THIS! And everything Richard’s written in this thread.

I’ve come to dread the process of making a deployable standalone, to the point 
where I actively avoid it. It’s a major PITA and headache inducer. This really 
is putting me off using LiveCode. I’m not saying ‘in preference to something 
else,’ just that the experience has become so convoluted and opaque that I work 
to avoid having to do it.

I’m sure others feel similarly, and that is a Very Not Good Thing for LiveCode.

:’(

k

---
Keith Martin
Mobile: +44 (0)7909 541365
360 media production, consultancy and training: PanoramaPhotographer.com
Exif Fixer 360 utility: ExifFixer.com
About me: thatkeith.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: Offtopic: Can anybody create a small DLL for me?

[Bob Sneidar via use-livecode]

On Windows it's pretty easy. On MacOS it's a little trickier. Here's a function 
I wrote to get the default connection, which contains methods for getting the 
network adapters for Windows and MacOS. Enjoy:

FUNCTION getDefaultNetwork pMode
   -- leave pMode empty for just IP and MAC info. Pass "Detail" to get more info
   IF the platform contains "WIN" THEN
  set hideconsolewindows to true
  put "netsh interface ip show config" into tShellCommand
  
  TRY
 put shell(tShellCommand) into tDefaultAdapter
  CATCH tError
 return tError
  END TRY
  
  -- if pMode is detail just return these results
  IF pMode is "Detail" THEN return tDefaultAdapter
  
  -- get the default adapter and Gateway IP addresses
  put lineoffset("IP Address:", tDefaultAdapter) into tIPAddressLine
  put word -1 of line tIPAddressLine of tDefaultAdapter into tLocalIPAddress
  put lineoffset("Default Gateway:", tDefaultAdapter)  into tGWAddressLine
  put word -1 of line tGWAddressLine of tDefaultAdapter into tGWIPAddress
  
  -- get the default adapter and gateway MAC addresses
  put "ipconfig /all" into tShellCommand
  
  TRY
 put shell(tShellCommand) into tConfigData
  CATCH tError
 return tError
  END TRY
  
  put lineoffset(tLocalIPAddress, tConfigData) -3 into tLocalMACLine
  put word -1 of line tLocalMACLine of tConfigData into tLocalMACAddress
  put "arp -a" into tShellCommand
  
  TRY
 put shell(tShellCommand) into tArpData
  CATCH tError
 return tError
  END TRY
  
  put lineoffset(tGWIPAddress, tArpData) into tGWMACAddressLine
  put word 2 of line tGWMACAddressLine of tArpData into tGWMACAddress
  
  put tLocalIPAddress && tLocalMACAddress & cr & \
 tGWIPAddress && tGWMACAddress into tCurrentAdapterInfo
   ELSE
  -- first we need to get the default adapter
  put "route get default" into tShellCommand
  
  TRY
 put shell(tShellCommand) into tDefaultAdapter
  CATCH tError
 return tError
  END TRY
  put lineoffset("Interface: ", tDefaultAdapter) into tInterfaceLine
  
  IF tInterfaceLine = 0 THEN
 return "ERROR: No default interface found!"
  END IF
  
  -- now we need the detail of the interface
  put word 2 of line tInterfaceLine of tDefaultAdapter into 
tDefaultInterface
  put "ipconfig getpacket " & tDefaultInterface into tShellCommand
  
  TRY
 put shell(tShellCommand) into tInterfaceDetail
  CATCH tError
 return tError
  END TRY
  
  -- if we didn't specifically ask for the interface and router MAC 
addresses, return here
  IF pMode is "Detail" THEN return tInterfaceDetail
  
  -- now we get  the interface MAC address
  put lineoffset("chaddr", tInterfaceDetail) into tInterfaceMACLine
  put word -1 of line tInterfaceMACLine of tInterfaceDetail into 
tDefaultMACAddress
  
  -- and the IP address
  put lineoffset("yiaddr", tInterfaceDetail) into tInterfaceIPLine
  put word -1 of line tInterfaceIPLine of tInterfaceDetail into 
tDefaultIPAddress
  
  -- next we get the router IP address
  put lineoffset("router (ip_mult): ", tInterfaceDetail) into tRouterLine
  put word 3 of line tRouterLine of tInterfaceDetail into tRouterIPAddress
  put char 2 to -2 of tRouterIPAddress into tRouterIPAddress
  
  -- next we get the MAC address of the router interface
  put "arp " & tRouterIPAddress into tShellCommand
  
  TRY
 put shell(tShellCommand) into tArpReply
  CATCH tError
 return tError
  END TRY
  
  put word 4 of tArpReply into tRouterMACAddress
  
  -- finally we return the MAC addresses of the default interface and the 
router interface
  put tDefaultIPAddress && tDefaultMACAddress & cr & \
 tRouterIPAddress && tRouterMACAddress into tCurrentAdapterInfo
   END IF
   
   return tCurrentAdapterInfo
END getDefaultNetwork

Bob S

> On Apr 13, 2021, at 05:27 , Tiemo via use-livecode 
>  wrote:
> 
> Thanks Matthias and Andre for pointing out for these options
> 
> Tiemo
> 
> 
> -Ursprüngliche Nachricht-
> Von: use-livecode  Im Auftrag von 
> Andre Garzia via use-livecode
> Gesendet: Dienstag, 13. April 2021 11:38
> An: How to use LiveCode 
> Cc: Andre Garzia 
> Betreff: Re: Offtopic: Can anybody create a small DLL for me?
> 
> Tiemo,
> 
> Maybe it is possible to parse the result of
> 
> shell(“ipconfig /all”)
> 
> To get the same information. I’m not sure which information you’re collecting 
> but I just run that on my windows and I could see every interface and the 
> info about them.
> 
> Best
> A

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

Re: On the dangers of automated refactoring

[Paul Dupuis via use-livecode]

I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would like 
to see better integrated into the IDE. This plugin was done by Mark 
Wieder and is not an official part of the LiveCode IDE, but it is one 
place, I would very much like to see the mothership either expand on 
Mark's or roll their own, but integrate similar refactoring capabilities 
into the IDE. For example, I frequently forget what some of the menu 
items do and there is no easily accessible built in documentation like 
for much of LiveCode in general. I'd like to see it be more visible - 
its own menu in the script editor or elevated in some way. I have on 
occasion forgot I have it installed and manually renamed a handler when 
revRefactor can doing for me in a few clicks. The "Find Orphan Code" 
feature is really great, but there is not spinning busy cursor or 
progress indicate. Once when running on a old, large code base, I 
thought revFactor had hung as it took so long to display the results. 
I'd pay more for my business license to see these integrated into the 
business edition.



___
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: Intermittent typing delay in script editor.

[Bob Sneidar via use-livecode]

Long scripts seems to be the recipe, at least for me. 

Bob S


> On Apr 13, 2021, at 03:11 , Andre Garzia via use-livecode 
>  wrote:
> 
> I see it on my two windows machine but never on the mac…. It is intermittent 
> and I’m yet to find a recipe, but it is real.
> 
>> On 8 Apr 2021, at 18:17, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 4/8/21 9:52 AM, thompsonmichael--- via use-livecode wrote:
>> 
>>> LC normally works lightning fast on this setup but over the last couple of
>>> years I would occasionally experience a sudden slow down in the script
>>> editor for no apparent reason. (Delays of seconds sometimes between typing
>>> and the type appearing on the screen) I would close everything and restart
>>> Livecode and all would be well again.
>> 
>> I see this on linux occasionally as well. It's erratic enough for me to 
>> suspect my own code, but I can never pin anything down. I'll keep an eye on 
>> my message box use. Thanks for the hint.
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.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

[Mark Wieder via use-livecode]

On 4/13/21 3:05 AM, Andre Garzia via use-livecode 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


Ouch. Don't do that.

I end up spending most of my coding life refactoring existing code. And 
while I do automated things, I'm *very* wary about the results if I'm 
working on a large corpus of code: save everything, make a copy of 
everything, save that somewhere else, do the refactor thing, make sure 
it still works, commit to git, rinse and repeat.


Also, if the source is somewhere like dropbox then you have access to 
previous builds as a backup.


--
 Mark Wieder
 ahsoftw...@gmail.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: [ANN] Release 9.6.2 RC-4

[Mark Waddingham via use-livecode]

On 2021-04-13 16:15, Mark Wieder via use-livecode wrote:

Do the release notes need updating?


Hah! Yes - we've had a 64-bit windows build (separate installer) 
available since 9.5.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: [ANN] Release 9.6.2 RC-4

[Mark Wieder via use-livecode]

On 4/13/21 4:48 AM, Mark Waddingham via use-livecode wrote:

No - its either running as a 32-bit app (if you have installed the 
32-bit version of LC) or as a 64-bit app (if you have installed the 
64-bit version of LC) - there's no emulation going on - the difference 
is the processor mode the executables are run in.


Windows, macOS and Linux all handle 32-bit vs 64-bit exactly the same 
way... The versions of the OS which can run both, have two sets of code 
for everything in the OS - one 32-bit and one 64-bit. The only 
difference is what those OSes call it / how they package it.


Hmmm... the release notes under Platform support | Windows says

"Note: On 64-bit Windows installations, LiveCode runs as a 32-bit 
application through the WoW layer."


Do the release notes need updating?

--
 Mark Wieder
 ahsoftw...@gmail.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

[Brian Milby via use-livecode]

There is a test framework in the GitHub repository:

https://github.com/livecode/livecode/tree/develop/tests

Didn’t really see documentation on it, but I’m sure it could be documented and 
used to generate a robust unit test of our own projects.  Plenty of examples 
there on use, just nothing on how to easily kick it off for your own projects.

Sent from my iPad

> On Apr 13, 2021, at 6:07 AM, Andre Garzia via use-livecode 
>  wrote:
> 
> Hi Folks,
> 
> I’ve recently read that long thread that almost got people banned and will 
> not comment on it. What I want to comment on is about the kernel of the 
> activity that was mentioned there: refactoring.
> 
> Often in LiveCode (and most programming languages to be honest) we go coding 
> for a long while and then realise that our code need extensive refactoring. 
> We may have repeated a pattern over and over again and discovered that we 
> need to change every instance of them, or something similar.
> 
> There are small cases of refactoring, such as renaming a variable in a single 
> script, that can be easily (and quite safely) be done with find & replace 
> tools. Others are much more complex and attempting to do it over multiple 
> scripts on a large project will result in crying and maybe needing a drink or 
> hug.
> 
> An example of a really smart IDE that is considered the most advanced in 
> terms of refactoring are the ones based on JetBrains IDEA such as IDEA 
> itself, Android Studio, webStorms, etc. A key part of these IDEs to do 
> refactoring is that they have deep knowledge about the source code being 
> written. The code is constantly parsed and assembled in a AST that is exposed 
> internally for the refactoring tools. When you refactor code in these IDEs, 
> you’re not really working with text, you’re telling the IDE to manipulate a 
> tree in ways the IDE knows how to manipulate such tree. That is why when you 
> “rename a symbol” or “extract selected code into method in enclosing scope” 
> or whatever you do in these IDEs, you end up with the expected result.
> 
> Find and Replace dialogs, or even custom plugins in LiveCode, don’t have the 
> same advanced capabilities. You’re usually working with text and hoping that 
> whatever RegEx you’re applying is error-free. And by error-free I don’t mean 
> it is a “valid regex”, I mean that “it does what you expect, and your 
> expectations are correct”. It is very hard to apply script transformations 
> like that, you can’t be sure they’ll work for every little replacement, and 
> for the cases where it doesn’t work, the bugs introduced might be too subtle 
> to notice. Let me tell you folks a recent story in which I tried to do 
> exactly that and shot myself on the foot.
> 
> I’m dealing with a very large LC app. Very large, thousands and thousands of 
> lines spread in a gazilion stacks, behaviors, and libraries. Some of these 
> files needed refactoring. Among the various tasks I needed to do was to apply 
> our “variable naming scheme” to the scripts because there were variables 
> using the wrong prefixes. 
> 
> Naturally, I tried being smart with find & replace. Even going as far as 
> extracting the script into an editor with more features —such as RegEx 
> replacing— and trying my best to identify and replace the names I needed with 
> vast swoops of RegEx.
> 
> All the replacements worked like I wrote them.
> 
> 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. 
> 
> I broke all the source code. It took me a long time to work out which 
> handlers needed arguments, and which didn’t need and were actually using the 
> script-local vars.
> 
> I tried being smart fixing broken code, and for a while it became more broken.
> 
> Refactoring is hard.
> 
> We don’t have a system to create and manipulate LC AST.
> 
> We don’t even have unit testing libraries so that we can make sure our code 
> works as expected.
> 
> Avoid large automated refactoring at all cost, it is not worth it. Do it 
> manually. It will be slower, but it will be safer.
> 
> Best
> A
> ___
> 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Ken Ray via use-livecode]

> On Apr 13, 2021, at 5:28 AM, Andre Garzia via use-livecode 
>  wrote:
> 
> I like all that I read here. There are things that are really hard when 
> building standalone apps that I don’t think should be handled by LC HQ, such 
> as “adding AppleScript dictionary” to your app. This is harder than it seems 
> and it involves plist manipulation, fancy sdef xml creation, etc. This is too 
> large a product to develop with a small target base.
> 
> On the other hand, I think that the SB should create standalones that can 
> actually be deployed, this means that it should be able to handle 
> notarisation on the mac out-of-the-box.

Amen, brother! 

:)


Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Website: https://www.sonsothunder.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

[Mark Smith via use-livecode]

I can't speak for others, but I can personally vouch for the authenticity of 
that statement 

On 2021-04-13, 12:12 PM, "use-livecode on behalf of Andre Garzia via 
use-livecode"  wrote:


I bet many here never used a unit testing library.



___
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

AW: Offtopic: Can anybody create a small DLL for me?

[Tiemo via use-livecode]

Thanks Matthias and Andre for pointing out for these options

Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode  Im Auftrag von Andre 
Garzia via use-livecode
Gesendet: Dienstag, 13. April 2021 11:38
An: How to use LiveCode 
Cc: Andre Garzia 
Betreff: Re: Offtopic: Can anybody create a small DLL for me?

Tiemo,

Maybe it is possible to parse the result of

shell(“ipconfig /all”)

To get the same information. I’m not sure which information you’re collecting 
but I just run that on my windows and I could see every interface and the info 
about them.

Best
A

> On 12 Apr 2021, at 10:43, Tiemo via use-livecode 
>  wrote:
> 
> Hello,
> 
> 
> 
> over ten years ago, I included a windows dll into one of my main LC 
> programs, which was created by a programmer, to whom I no more have 
> any contact.
> 
> The dll only has one single function, it reads all MAC addresses from 
> the device with all related informations, like name and kind of 
> address and gives all the data back to LC.
> 
> 
> 
> Now I would like to build a 64Bit version of my program and therefor 
> need a 64Bit version of this dll. I don't have the source, so it has 
> to be created from the scratch.
> 
> 
> 
> If there is anybody, who is willing to do this paid job for me, please 
> contact me PM: toolb...@kestner.de 
> 
> 
> 
> Thank you
> 
> 
> 
> Tiemo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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: [ANN] Release 9.6.2 RC-4

[Mark Waddingham via use-livecode]

On 2021-04-09 22:25, Bob Sneidar via use-livecode wrote:

Ya so LC for Windows is basically running in an emulator.


No - its either running as a 32-bit app (if you have installed the 
32-bit version of LC) or as a 64-bit app (if you have installed the 
64-bit version of LC) - there's no emulation going on - the difference 
is the processor mode the executables are run in.


Windows, macOS and Linux all handle 32-bit vs 64-bit exactly the same 
way... The versions of the OS which can run both, have two sets of code 
for everything in the OS - one 32-bit and one 64-bit. The only 
difference is what those OSes call it / how they package it.


On Windows, the 32-bit set of libraries is called WoW 
(Windows-on-Windows), on Linux its called 'multi-arch' or 'multilib' (I 
think at least?), on macOS its called 'universal executables'.


macOS does have the advantage that the Mach-O binary executable format 
allows multiple architectures in the same binary which means it is all 
entirely hidden from the user. Neither PE (Windows) nor ELF (Linux) 
allow that, so user ends up having to choose the appropriate installer / 
run the appropriate installer command.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

How do I change the textcolor of the selected text in a native iOS field?

[William de Smet via use-livecode]

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.

How do I adapt this code I made? (this obviously only returns the first
char of the text in red)

-
on changeColor
mobileControlDo "field1", "focus", true
put mobileControlGet ("field1", "text") into tText
put char 1 of tText into tColor
mobileControlSet "field1" , "text", "" & tColor
mobileControlSet "field1", "textcolor", "255,0,0"
on changeColor


greetings,

William
___
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]

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

Re: On the dangers of automated refactoring

[Peter W A Wood via use-livecode]

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

Re: On the dangers of automated refactoring

[David Bovill via use-livecode]

Hence the value of crowd-funding a version of the LiveCode language for the 
Graalvm.

I spend a great deal of my time in LiveCode refactoring and renaming handlers. 
I’ve done this not so much because it is useful to my productivity, but because 
I see a method in the madness of spaghetti code that is worth exploring with 
the tools of collaborative authoring. I’d be interested to understand the 
nature of the gazillion stack project to see how it compares to my gazillion 
stack project (and I presume others). We could learn things by comparing 
approaches.
On 13 Apr 2021, 11:07 +0100, Andre Garzia via use-livecode 
, wrote:
> Hi Folks,
>
> I’ve recently read that long thread that almost got people banned and will 
> not comment on it. What I want to comment on is about the kernel of the 
> activity that was mentioned there: refactoring.
>
> Often in LiveCode (and most programming languages to be honest) we go coding 
> for a long while and then realise that our code need extensive refactoring. 
> We may have repeated a pattern over and over again and discovered that we 
> need to change every instance of them, or something similar.
>
> There are small cases of refactoring, such as renaming a variable in a single 
> script, that can be easily (and quite safely) be done with find & replace 
> tools. Others are much more complex and attempting to do it over multiple 
> scripts on a large project will result in crying and maybe needing a drink or 
> hug.
>
> An example of a really smart IDE that is considered the most advanced in 
> terms of refactoring are the ones based on JetBrains IDEA such as IDEA 
> itself, Android Studio, webStorms, etc. A key part of these IDEs to do 
> refactoring is that they have deep knowledge about the source code being 
> written. The code is constantly parsed and assembled in a AST that is exposed 
> internally for the refactoring tools. When you refactor code in these IDEs, 
> you’re not really working with text, you’re telling the IDE to manipulate a 
> tree in ways the IDE knows how to manipulate such tree. That is why when you 
> “rename a symbol” or “extract selected code into method in enclosing scope” 
> or whatever you do in these IDEs, you end up with the expected result.
>
> Find and Replace dialogs, or even custom plugins in LiveCode, don’t have the 
> same advanced capabilities. You’re usually working with text and hoping that 
> whatever RegEx you’re applying is error-free. And by error-free I don’t mean 
> it is a “valid regex”, I mean that “it does what you expect, and your 
> expectations are correct”. It is very hard to apply script transformations 
> like that, you can’t be sure they’ll work for every little replacement, and 
> for the cases where it doesn’t work, the bugs introduced might be too subtle 
> to notice. Let me tell you folks a recent story in which I tried to do 
> exactly that and shot myself on the foot.
>
> I’m dealing with a very large LC app. Very large, thousands and thousands of 
> lines spread in a gazilion stacks, behaviors, and libraries. Some of these 
> files needed refactoring. Among the various tasks I needed to do was to apply 
> our “variable naming scheme” to the scripts because there were variables 
> using the wrong prefixes.
>
> Naturally, I tried being smart with find & replace. Even going as far as 
> extracting the script into an editor with more features —such as RegEx 
> replacing— and trying my best to identify and replace the names I needed with 
> vast swoops of RegEx.
>
> All the replacements worked like I wrote them.
>
> 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.
>
> I broke all the source code. It took me a long time to work out which 
> handlers needed arguments, and which didn’t need and were actually using the 
> script-local vars.
>
> I tried being smart fixing broken code, and for a while it became more broken.
>
> Refactoring is hard.
>
> We don’t have a system to create and manipulate LC AST.
>
> We don’t even have unit testing libraries so that we can make sure our code 
> works as expected.
>
> Avoid large automated refactoring at all cost, it is not worth it. Do it 
> manually. It will be slower, but it will be safer.
>
> Best
> A
> ___
> 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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Andre Garzia via use-livecode]

I like all that I read here. There are things that are really hard when 
building standalone apps that I don’t think should be handled by LC HQ, such as 
“adding AppleScript dictionary” to your app. This is harder than it seems and 
it involves plist manipulation, fancy sdef xml creation, etc. This is too large 
a product to develop with a small target base.

On the other hand, I think that the SB should create standalones that can 
actually be deployed, this means that it should be able to handle notarisation 
on the mac out-of-the-box.

> On 29 Mar 2021, at 22:49, Trevor DeVore via use-livecode 
>  wrote:
> 
> On Mon, Mar 29, 2021 at 4:35 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
> 
>> I think we're all on the same page here.
>> 
> 
> :thumbs_up
> 
> -- 
> Trevor DeVore
> ScreenSteps
> www.screensteps.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: Intermittent typing delay in script editor.

[Andre Garzia via use-livecode]

I see it on my two windows machine but never on the mac…. It is intermittent 
and I’m yet to find a recipe, but it is real.

> On 8 Apr 2021, at 18:17, Mark Wieder via use-livecode 
>  wrote:
> 
> On 4/8/21 9:52 AM, thompsonmichael--- via use-livecode wrote:
> 
>> LC normally works lightning fast on this setup but over the last couple of
>> years I would occasionally experience a sudden slow down in the script
>> editor for no apparent reason. (Delays of seconds sometimes between typing
>> and the type appearing on the screen) I would close everything and restart
>> Livecode and all would be well again.
> 
> I see this on linux occasionally as well. It's erratic enough for me to 
> suspect my own code, but I can never pin anything down. I'll keep an eye on 
> my message box use. Thanks for the hint.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.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: [ANN] Release 9.6.2 RC-4

[Andre Garzia via use-livecode]

> On 9 Apr 2021, at 20:49, JeeJeeStudio via use-livecode 
>  wrote:
> 
> Of course it's 32bits, even the builds are 32bits on windows except they are 
> packed in a 64bit container.

I’m not sure about that because my Surface Pro X can only run x86-32 apps and 
it can run LiveCode. If it was somehow wrapped in 64bits anything, it would say 
that it is not compatible with it.

___
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

On the dangers of automated refactoring

[Andre Garzia via use-livecode]

Hi Folks,

I’ve recently read that long thread that almost got people banned and will not 
comment on it. What I want to comment on is about the kernel of the activity 
that was mentioned there: refactoring.

Often in LiveCode (and most programming languages to be honest) we go coding 
for a long while and then realise that our code need extensive refactoring. We 
may have repeated a pattern over and over again and discovered that we need to 
change every instance of them, or something similar.

There are small cases of refactoring, such as renaming a variable in a single 
script, that can be easily (and quite safely) be done with find & replace 
tools. Others are much more complex and attempting to do it over multiple 
scripts on a large project will result in crying and maybe needing a drink or 
hug.

An example of a really smart IDE that is considered the most advanced in terms 
of refactoring are the ones based on JetBrains IDEA such as IDEA itself, 
Android Studio, webStorms, etc. A key part of these IDEs to do refactoring is 
that they have deep knowledge about the source code being written. The code is 
constantly parsed and assembled in a AST that is exposed internally for the 
refactoring tools. When you refactor code in these IDEs, you’re not really 
working with text, you’re telling the IDE to manipulate a tree in ways the IDE 
knows how to manipulate such tree. That is why when you “rename a symbol” or 
“extract selected code into method in enclosing scope” or whatever you do in 
these IDEs, you end up with the expected result.

Find and Replace dialogs, or even custom plugins in LiveCode, don’t have the 
same advanced capabilities. You’re usually working with text and hoping that 
whatever RegEx you’re applying is error-free. And by error-free I don’t mean it 
is a “valid regex”, I mean that “it does what you expect, and your expectations 
are correct”. It is very hard to apply script transformations like that, you 
can’t be sure they’ll work for every little replacement, and for the cases 
where it doesn’t work, the bugs introduced might be too subtle to notice. Let 
me tell you folks a recent story in which I tried to do exactly that and shot 
myself on the foot.

I’m dealing with a very large LC app. Very large, thousands and thousands of 
lines spread in a gazilion stacks, behaviors, and libraries. Some of these 
files needed refactoring. Among the various tasks I needed to do was to apply 
our “variable naming scheme” to the scripts because there were variables using 
the wrong prefixes. 

Naturally, I tried being smart with find & replace. Even going as far as 
extracting the script into an editor with more features —such as RegEx 
replacing— and trying my best to identify and replace the names I needed with 
vast swoops of RegEx.

All the replacements worked like I wrote them.

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. 

I broke all the source code. It took me a long time to work out which handlers 
needed arguments, and which didn’t need and were actually using the 
script-local vars.

I tried being smart fixing broken code, and for a while it became more broken.

Refactoring is hard.

We don’t have a system to create and manipulate LC AST.

We don’t even have unit testing libraries so that we can make sure our code 
works as expected.

Avoid large automated refactoring at all cost, it is not worth it. Do it 
manually. It will be slower, but it will be safer.

Best
A
___
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: Offtopic: Can anybody create a small DLL for me?

[Andre Garzia via use-livecode]

Tiemo,

Maybe it is possible to parse the result of

shell(“ipconfig /all”)

To get the same information. I’m not sure which information you’re collecting 
but I just run that on my windows and I could see every interface and the info 
about them.

Best
A

> On 12 Apr 2021, at 10:43, Tiemo via use-livecode 
>  wrote:
> 
> Hello,
> 
> 
> 
> over ten years ago, I included a windows dll into one of my main LC
> programs, which was created by a programmer, to whom I no more have any
> contact.
> 
> The dll only has one single function, it reads all MAC addresses from the
> device with all related informations, like name and kind of address and
> gives all the data back to LC.
> 
> 
> 
> Now I would like to build a 64Bit version of my program and therefor need a
> 64Bit version of this dll. I don't have the source, so it has to be created
> from the scratch.
> 
> 
> 
> If there is anybody, who is willing to do this paid job for me, please
> contact me PM: toolb...@kestner.de  
> 
> 
> 
> Thank you
> 
> 
> 
> Tiemo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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