Re: Resize Images in on-rev folder via lc script?

[Alex Tweedly via use-livecode]

Yes, it is possible - here's the relevant section of the .lc file I used 
to use to do it.


(it's from my script-only library that I use on both LCServer and 
desktop/IDE, hence the 'lockscreen's


I would use this by uploading the file (usually to a folder called 
'originals' or something like that), and then resizing to more 
imaginatively named folders such as 'width90' or 'width600' for 
different purposes.


-- image handling and resizing
command setAreaProportional pImageID, pWidth, pHeight
   local tProportionalWidth, tProportionalHeight, tRatio

   put (the formattedWidth of pImageID) / pWidth into tRatio
   put (the formattedHeight of pImageID) / tRatio into tProportionalHeight

   put (the formattedHeight of pImageID) / pHeight into tRatio
   put (the formattedWidth of pImageID) / tRatio into tProportionalWidth

   if tProportionalHeight > pHeight then
  lock screen
  set the width of pImageID to tProportionalWidth
  set the height of pImageID to pHeight
  unlock screen
   else
  lock screen
  set the width of pImageID to pWidth
  set the height of pImageID to tProportionalHeight
  unlock screen
   end if
end setAreaProportional

function resizeImageFile pFile, pOutFile, pMaxWid, pMaxHeight
   local t, tt

   import paint from file pFile
   put the name of the last image into t
   set the name of t to "Im1"

   clone img "Im1"
   set the name of it to "Im2"
   setAreaProportional the long id of img "Im2", pMaxWid, pMaxHeight
   export img "Im2" to file pOutFile as jpeg
   put the result into tt

   delete img "Im2"
   delete img "Im1"

   return empty  -- "Done resize" & ":" & tt & ":" && pFile && pOutfile
end resizeImageFile

-- Alex.


On 12/03/2017 22:29, JOHN PATTEN via use-livecode wrote:

Hi All,

I have a simple html form that uploads images to a directory on the on-rev 
server. The images are uploaded at different resolutions. I would like to have 
the on-rev server resize the width of the images  in that folder when users 
drop them into the server via an html form.

Is it possible using lc scripts on the on-rev server to resize the images? I can do 
the resize easily via a stack using the example here, 
http://lessons.livecode.com/m/4071/l/15018-how-to-proportionally-resize-an-image 

 , but I’m not sure how that could be applied to a folder on the server using .lc 
scripts?

Thank you!
John Patten
SUSD


___
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

Resize Images in on-rev folder via lc script?

[JOHN PATTEN via use-livecode]

Hi All,

I have a simple html form that uploads images to a directory on the on-rev 
server. The images are uploaded at different resolutions. I would like to have 
the on-rev server resize the width of the images  in that folder when users 
drop them into the server via an html form.

Is it possible using lc scripts on the on-rev server to resize the images? I 
can do the resize easily via a stack using the example here, 
http://lessons.livecode.com/m/4071/l/15018-how-to-proportionally-resize-an-image
 

 , but I’m not sure how that could be applied to a folder on the server using 
.lc scripts?

Thank you!
John Patten
SUSD


___
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 10 Screen resolution problem

[Charles Szasz via use-livecode]

I posted the following year but never received a solution:

An user reported seeing a screen resolution dialog in one of my programs that 
requests a screen resolution of 1024x768 be used. The problem is that  the user 
reportedly is using a screen resolution of 1920x1080.   She is using Windows 
10. 

I am using LC 6.1.2 and use the following code in my app stack: 

on checkForScreenSize 

   IF the platform is "win32" 
   then 
  if item 3 of the screenRect < 1024 or item 4 of the screenRect < 768 then 
 answer error "The Assistant software requires a minimum 1024x768 
screen resolution. Please check your Control Panel." with "OK" 
 quit 
  end if 
   end if 

   if the platform = "MacOS" 
   then 
  if item 3 of the screenRect < 1024 or item 4 of the screenRect < 768 then 
 answer error "The Assistant software requires a minimum 1024x768 
screen resolution. Please check your Display Preferences." with "OK" 
 quit 
  end if 
   end if 
  
end checkForScreenSize 

Has anybody encountered this problem with Windows 10? 



Sent from my iPad
___
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: LC for Raspberry Pi

[hh via use-livecode]

People who are using a Raspi and try or even use LC on it may be inclined to
try or use LC if they 'expand' to a tablet or desktop.

And their own creations will work after no or small adjustments, WOW. This
may cause (delayed) revenue to LC.

> Mike K. wrote:
> Pi is interesting to me because of what I can, in theory, build with it,
> but for the same reason so are many other things.  Pi isn't going to bring
> revenue to LC, IMHO, the way that some of those other tools can, but being
> able to brag about being the easy-to-use IDE for PI would be cool.

___
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: Messages sent while mouse is down?

[Jim Lambert via use-livecode]

> Tim wrote:
> 
> Click and drag the mouse through 
> adjacent letters to make words.
> 
> Without clicking, simply moving the mouse through the tiles 
> (fields) triggers mouseenter, mouseleave, etc. which makes it 
> easy to pick up the letters.
> 
> But when the mouse is down, it seems mouseloc() is the only thing 
> I can get. Using a variable what has all the field rectangles, I 
> can use the mouseloc() to ultimately identify the field under the 
> pointer, but it's too slow...
> 
> 

How about a slight change in the game’s instructions?

Instead of "click and drag through the letters to highlight a word", have the 
user click on the first letter of their word, mouse through the intervening 
letters, and finally click on the last letter of their word to end their word 
discovery process.

That way you entirely avoid having to track the mouseloc while the mouse is 
down. 
Use the first click (mouseup) to begin ‘recording’ the user’s word discovery. 
That will tell you letter #1 of their word.
Then use subsequent mouseenters to track which letters the user moved into next 
and the order of entry. That will tell you the rest of the letters in their 
word.
Use the next click (mouseup) to end their word discovery process.
Then you compare their word to your dictionary to see if it is a legit word.

Of course, you'll want to account for clicks outside of the play area and 
ignore them or restrict mouse movement to the play area during the word 
discovery process.

Jim Lambert 
___
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: LC for Raspberry Pi

[Mike Kerner via use-livecode]

Pi is interesting to me because of what I can, in theory, build with it,
but for the same reason so are many other things.  Pi isn't going to bring
revenue to LC, IMHO, the way that some of those other tools can, but being
able to brag about being the easy-to-use IDE for PI would be cool.

On Sat, Mar 11, 2017 at 5:14 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> hh wrote:
>
> > Richard.
> >
> > Thanks for your engagement. I would like to second this with 98%.
> >
> > Let me correct two of your statements (the missing 2%).
> >
> > 1.
> >> RG wrote:
> >> The last RPi build was v704, which is generally good with one
> >> critical issue:  a bug in the menu handling routine causes a crash
> >> when clicking in a menubar.
> > That's wrong in that generality. I have four Raspi's running
> > (one A with Debian, two B+ with Lubuntu or Debian resp., one 3 with
> > Xubuntu or Debian resp., the Debian needs to be first installed on
> > a 2B+, see forum). So install an appropriate OS and it works. Though
> > 3-5 imes slower than v651.
>
> It's nice to know it can work well with certain distros, but for myself
> (focused on a goal of adoption) an "appropriate OS" is the one most
> commonly used.  I ran my tests on the latest stock Raspian most prominently
> available at raspberrypi.org at the time.
>
> If LC won't run on the most common build (and it seems to except for that
> one bug), it's time for a fresh compile.  Hopefully it won't be much longer.
>
>
> > 2.
> >> RG wrote:
> >> So for me, if I had to deliver a GUI for RPi I'd much rather use a
> >> workflow similar to what we do with mobile:  develop on a fully-
> >> spec'd desktop machine, and deploy to the device.
> >
> > If "I'd" means "I would" then I'd say once again (I told you in the
> > forum):
> > This is the way I did from the beginning of the existence of __LC
> > 704__, which is the only one that has a Raspi-deployment option
> > (Linux ARMv6-HF).
> > Simply copy the standalone created on your desktop box to your Raspi
> > via sftp (what may be even scripted) or via an USB stick.
> >
> > So if developers optimize for speed (as LC 7 is 3-5 times slower than
> > LC 6) they can have this, since years. By ONE click and ONE data
> > transfer.
>
> When we get a fresh build with v9 I think we'll see many speed
> improvements in the RPi engine (see earlier reply to jonathandlynch).
>
> V6 is nice, but old.  It would be ideal to keep formats and features in
> sync with the rest of the LC world.
>
> And the work Fraser and other have done in v7 and v8 for better GTK
> integration has been superb, at least in the Gnome-based DE's I'm using
> (Unity in Ubuntu and LXDE in Lubuntu).
>
> But regardless of version, it seems we're on the same page with a worklow
> that favors building on the desktop and running on the RPi.
>
> In fact, this morning I was curious about Xojo's system requirements for
> their RPi deployments, and it seems Xojo isn't available for RPi - that is,
> not the IDE.  They have a runtime engine only, so the workflow they require
> is the same one you and I recommend with LC, building on desktop to run on
> RPi.
>
> Still, given the many EDU use cases where having an IDE on the RPi would
> be desirable, I'd like to explore options for a lightweight IDE down the
> road (though probably way down the road for me; lots of other priorities
> before that).
>
> --
>  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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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