A DataGrid is not a spreadsheet

[Javier Miranda V.]

Dear friends, is it safe to say that a data grid is not a spreadsheet? I mean, 
you can not create a new data grid and then just click in a empty cell and 
enter data. 

With some practice and reading documentation, I am able to populate a datagrid 
with data from a database, and using a Table field in situation in which the 
user must fill-in data seems limited.  


Saludos, 

Javier Miranda V.
___
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: When is open stack sent on Mobile

[Sannyasin Brahmanathaswami]

Make sense, the dictionary doesn't state explicitly that a resizeStack msg is 
sent when orientation is changed.. that's why I did not go that route, but 
looking at the

orientationChanged  

entry…  which says 

" If you wish to perform an action after the interface has been rotated, then 
either do so on receipt of resizeStack, or by using a send in 0 milliseconds 
command."

it infers that resizeStack is sent.. 

I'll try that.



 

On 7/28/16, 9:05 AM, "use-livecode on behalf of J. Landman Gay" 
 
wrote:

Yeah, what Richard said. Use resizeStack to reset the UI. I think 
specifically setting the rect of the stack may cause issues when you run 
on Android where window sizes are all over the place.

I'd let the engine manage the stack size by using the fullScreenMode 
property, and set up all your objects using relative coords rather than 
hard-coded ones.

___
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: Destroy Browser Window

[Sannyasin Brahmanathaswami]

setting the URL for the browser widget to empty doesn't destroy the region… all 
it does it turns it "white" (empty)  so now you have a white block overlaying 
the stack "permanently"  with no means to dismiss.


On 7/28/16, 10:28 AM, "use-livecode on behalf of Sannyasin Brahmanathaswami" 
 wrote:

But, there is this in the LCB file… perhaps all it takes is setting the URL 
of the browser to empty? will try that… but still seems like there should be a 
higher level "destroy browser instance" for the new browser widget

private handler clearBrowser()
  setHtmlText(the empty string)
end handler

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

Destroy Browser Window

[Sannyasin Brahmanathaswami]

I posted this, perhaps prematurely, as a bug..

I am unable to find the equivalent of

revBrowserClose instanceID

for the new browser widget.

as such… the widget/window/rect and it's content persist on screen on mobile as 
you open and close other cards/stacks

Am I missing something?  I did my home work, studied the dictionary and even 
opened the browser.lcb file

I don't see anything close

But, there is this in the LCB file… perhaps all it takes is setting the URL of 
the browser to empty? will try that… but still seems like there should be a 
higher level "destroy browser instance" for the new browser widget

private handler clearBrowser()
  setHtmlText(the empty string)
end handler

BR

___
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: When is open stack sent on Mobile

[J. Landman Gay]

On 7/28/2016 12:46 PM, Sannyasin Brahmanathaswami wrote:

switching from landscape to portrait -- similarly one must re-set up
the UI explicitly and typically the old way of doing such would be in
a preopen or open stack handlers… again, these need to fire when
moving back and forth. Just this morning I successfully was able to
go from a stack in portrait orientation lock to portrait, portrait
upside down to a landscape stack, lock to landscape right, left… and
back again…  but it required specifically setting the rect of the
stack to 0,0,414,716 in a preopen stack handler


Yeah, what Richard said. Use resizeStack to reset the UI. I think 
specifically setting the rect of the stack may cause issues when you run 
on Android where window sizes are all over the place.


I'd let the engine manage the stack size by using the fullScreenMode 
property, and set up all your objects using relative coords rather than 
hard-coded ones.


--
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: MORE HELP with: open printing for pdf...

[Paul Dupuis]

Hi Dan,

i am using revPrintText in my printing to PDF. i.e.

open printing to pdf tFile
revPrintText theHTMLText
close printing

where theHTMLText is basically 'the htmlText" or a target field. This is
working for me in *most* cases. Our field content that gets converted to
a PDF ranges from plain text to very rich content, including embedded
images in the field (via the imageSource of char x). This produces a
single, properly paged, PDF. However with some content - we have yet to
figure out what field content triggers it - we get a script execution
error in revPrintText

Object: property is not an integer: 4294907844 (Line 0, column 0)
Chunk: can't set property:  (Line 162, column 22)
Object: can't set object property: 4294907844 (Line 162, column 7)
set: can't set property: 4294907844 (Line 162, column 1)
repeat: error in statement:  (Line 141, column 1)
Handler: error in statement: revPrintText (Line 141, column 1)
Object ID: stack "revprintlibrary


So, we may have to change to using print card or something else. I have
no experience at using open printing for PDF with anything other than
revPrintText, so I am sorry, but I don't know what may be the cause of
the problem you've run into.

-- Paul

On 7/28/2016 2:11 PM, Dan Friedman wrote:
> Monte (and Paul),
>
> Thanks for reporting your findings.  I have been struggling with this issue 
> for some time (with LC 7.0.1).  Adding the default folder to the path to the 
> DLL fixed the problem.
>
> However, now that it's PDFing, a new problem exists.  If I "open printing to 
> pdf" and then run multiple "print card" commands, each print comes out as a 
> separate document and I am asked to select a location to save the output for 
> each page.   I haven't issues a "close printing" command yet, but it's still 
> outputting separate PDFs.  It works fine in the IDE, it works fine in the Mac 
> Standalone, but I get this odd behavior on with the Windows standalone.
>
> One note...   I "open printing to pdf" in stack A.  Then, I open stack B and 
> do the "print card" commands.  Then, I close stack B and stack A issues the 
> "close printing" command.  I then repeat as needed.   I don't think this 
> matters as it works in the IDE and on the Mac.
>
>
> Any thoughts?
>
> Thank you in advance!
> -Dan
>
>
>> On 27 Jul 2016, at 4:43 PM, Paul Dupuis  wrote:
>>
>> Monte,
>>
>> Thank you so much - exactly that - so for LC6.x I added the follow which
>> address the problem whether in the IDE or standalone
>>
>> put the defaultFolder into tSaveDefaultFolder
>> if (the environment is "development") then -- IDE
>> set the defaultFolder to specialFolderPath("engine")
>> else -- standalone
>> set the defaultFolder to appPath()
>> end if
>>
>> -- do my PDF printing
>>
>> set the defaultFolder to tSaveDefaultFolder
>>
>> If I every see you at a LiveCode Conference (I have to attend Edinburgh
>> via webcast this year), I owe you drinks or a meal or both!
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-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: When is open stack sent on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> switching from landscape to portrait
> -- similarly one must re-set up the UI explicitly and typically
> the old way of doing such would be in a preopen or open stack
> handlers…

I've been handling stack resizing with a resizeStack handler, sent to 
the card when the stack is first opened on mobile, and on all platforms 
whenever a stack is resized, such as via rotation of the device.


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

MORE HELP with: open printing for pdf...

[Dan Friedman]

Monte (and Paul),

Thanks for reporting your findings.  I have been struggling with this issue for 
some time (with LC 7.0.1).  Adding the default folder to the path to the DLL 
fixed the problem.

However, now that it's PDFing, a new problem exists.  If I "open printing to 
pdf" and then run multiple "print card" commands, each print comes out as a 
separate document and I am asked to select a location to save the output for 
each page.   I haven't issues a "close printing" command yet, but it's still 
outputting separate PDFs.  It works fine in the IDE, it works fine in the Mac 
Standalone, but I get this odd behavior on with the Windows standalone.

One note...   I "open printing to pdf" in stack A.  Then, I open stack B and do 
the "print card" commands.  Then, I close stack B and stack A issues the "close 
printing" command.  I then repeat as needed.   I don't think this matters as it 
works in the IDE and on the Mac.


Any thoughts?

Thank you in advance!
-Dan


> On 27 Jul 2016, at 4:43 PM, Paul Dupuis  wrote:
> 
> Monte,
> 
> Thank you so much - exactly that - so for LC6.x I added the follow which
> address the problem whether in the IDE or standalone
> 
> put the defaultFolder into tSaveDefaultFolder
> if (the environment is "development") then -- IDE
> set the defaultFolder to specialFolderPath("engine")
> else -- standalone
> set the defaultFolder to appPath()
> end if
> 
> -- do my PDF printing
> 
> set the defaultFolder to tSaveDefaultFolder
> 
> If I every see you at a LiveCode Conference (I have to attend Edinburgh
> via webcast this year), I owe you drinks or a meal or both!

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

Re: When is open stack sent on Mobile

[Sannyasin Brahmanathaswami]

@ Mark… thanks for the clarification

The current app we have in progress is modular… many, many stacks being called 
all of which are independent LC stacks (not substacks of anything). it works 
quite well on the desktop but on mobile there are caveats that have to be dealt 
with explicitly and "immediately" so to speak, when:

instantiating scrollers
 -- the standard implementation is to delete a scrolling regions when 
creating a new one, because you can't necessarily know where (what card, stack) 
the user is coming and going from and the ID and rect of the scroller that is 
required on any given card will differ. So if you are firing those on open 
stack, then you need to close it first.  I'm  a newbie at this mobile stuff, so 
perhaps over time we will find better architecture, but for now I've start 
issuing a "close this stack" on every move to a different "module" (stack) … 
this works. 

switching from landscape to portrait
-- similarly one must re-set up the UI explicitly and typically the old way 
of doing such would be in a preopen or open stack handlers… again, these need 
to fire when moving back and forth. Just this morning I successfully was able 
to go from a stack in portrait orientation lock to portrait, portrait upside 
down to a landscape stack, lock to landscape right, left… and back again…  but 
it required specifically setting the rect of the stack to 0,0,414,716 in a 
preopen stack handler

So  I've taken to using things like this throughout, because the user could be 
on card 3 of Stack 2, (portrait) moves to card 5 of Stack 6 (landscape)… so 
"Back" requires

command closeStopCloseGoRecent
   go recent
   close me # to ensure that future preopen and open stack handlers fire
end closeStopCloseGoRecent

so that when we go back to Stack 6.. the 

on preopenstack
   initializeInterfaceDefaults pOrientation 
# in which we explicitly set up card rect
# mobileSetAllowedOrientation  on the fly… 
end preopenstack

I'm sure others could analyze the frame work and come up with more optimized 
methods… but so far it's working!  I'm not sure that "go in window" gets us 
much more than what I'm doing now.

Slowly finding ways to moving thing to common backscripts and behaviors. But 
"who gets the message" can be tricky.  e.g. I'm told that "the script that 
creates mobile object gets it's subsequent messages… " OK… and it appears these 
message will not "cascade up" the message path. So still stuck on scrollers--I 
have the same script to instantiate scrollers in every stack, because the same 
methods that work in that context do not work if I move them to a single common 
behavior for the different stacks… I suspect because the preopencard handler is 
call the 

createScroller "portal-links" 

 and since the messages about this are sent back to the card… the behavior 
never gets it… most significantly, the cmd to delete existing scroller with 
different ID for that same or different region. 

Still wrestling with that one… or rather, threw in the towel after two days 
wasted trying to optimize the architecture.. I bailed and copied that 
createScroller handler to all the stacks… 

learning slowly…


On 7/28/16, 6:43 AM, "use-livecode on behalf of Mark Waddingham" 
 wrote:

Stacks on mobile and desktop work in the same way so if you 'go stack' 
then it opens the new stack (if it is not already open) and moves it 
(notionally) to the top (just as happens on desktop - the window of the 
target of 'go' is brought to the front of that layer).

If you use 'go stack ... in window ...' then it will close the current 
stack and open the new one.



___
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: When is open stack sent on Mobile

[Mark Waddingham]

On 2016-07-28 01:25, Sannyasin Brahmanathaswami wrote:

It appears on mobile you can issue

go stack "stackOne"

and then later

go stack "stackTwo"

and then you will only see "stackOne"

But if you have links that go backto "stackOne"  I'm not getting any
open stack or open card messages handlers to fire.  I suspect that's
because they are still.

Anyone else using multiple stacks in a mobile app…and found a way to
trap for when a stack does into the background and the comes back into
the foreground (takes over the screen() unfortunately, suspend and
resume, are not available on mobile.


Stacks on mobile and desktop work in the same way so if you 'go stack' 
then it opens the new stack (if it is not already open) and moves it 
(notionally) to the top (just as happens on desktop - the window of the 
target of 'go' is brought to the front of that layer).


If you use 'go stack ... in window ...' then it will close the current 
stack and open the new one.


The suspend / resume messages would be inappropriate here as they are to 
do with switching applications rather than windows (and are not 
currently sent on mobile).


The suspendStack / resumeStack messages are tied to window focus and 
aren't platform specific - they are sent when the stack with input focus 
changes. The fact they apparantly work on iOS and not Android is 
slightly strange, as that mechanism is implemented (on mobile) in the 
platform-independent code so it should work the same way on both. So, 
there is obviously something slightly amiss going on there.


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: When is open stack sent on Mobile

[Roger Eller]

What kind of Mickey Mouse operation is this anyway?!


On Thu, Jul 28, 2016 at 11:13 AM, Richard Gaskin  wrote:

> Sannyasin Brahmanathaswami wrote:
>
> > Anyone doing Android?
>
> Only 80% of smartphone users, 70% of tablet users, and now 100& of current
> Chromebook users too. :)
>
> > can you check to see if Suspend and Resume are passed to stacks
> > that come and go from the foreground of the app? (but are not
> > closed along the way..)
>
> I just tested suspend, resume, suspendStack, and resumeStack - all no-go
> on Android in LC 8.1dp2.
>
> --
>  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: When is open stack sent on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Anyone doing Android?

Only 80% of smartphone users, 70% of tablet users, and now 100& of 
current Chromebook users too. :)


> can you check to see if Suspend and Resume are passed to stacks
> that come and go from the foreground of the app? (but are not
> closed along the way..)

I just tested suspend, resume, suspendStack, and resumeStack - all no-go 
on Android in LC 8.1dp2.


--
 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: When is open stack sent on Mobile

[Sannyasin Brahmanathaswami]

@ Paul:  tks

OK I'll test for that… the dictionary is behind for many entries… so perhaps 
this is one of them.

Anyone doing Android? can you check to see if Suspend and Resume are passed to 
stacks that come and go from the foreground of the app? (but are not closed 
along the way..)

BR

 

On 7/27/16, 6:05 PM, "use-livecode on behalf of Paul Hibbert" 
 wrote:

A quick test shows that suspendStack and resumeStack do appear to work on 
the iOS simulator despite the omission of mobile platforms in the dictionary. 
Sorry I don’t have Android set up for testing right now.



___
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