Re: VFP top level menu on tablets and phones

POS systems are always using big buttons on touch screen. So you can convert Foxpro menu MNX definition into a button-based interface! http://fox.wikis.com/wc.dll?Wiki~ReadFoxProMenuFileToProduceButton-BasedMenu~Wiki On Fri, Apr 8, 2016 at 7:32 PM, Peter Cushing wrote: > I'm sure this has been d

Re: Okay team, I'm back

Quick guess is that you do not have auto increment set on your table. When you do that your insert need not send the value for the PK. Translation is you probably already have a 0 as an ID in the table and you are trying to add another one. On Mon, Apr 11, 2016 at 1:24 PM, Gary wrote: > For 10

Okay team, I'm back

For 10 plus years you guys coached me along and everything works well. Then I took off 3 or so years dabbling with html, php, and mysql. You guys got me over the hump trading data between fox-pro and mysql. Somewhere in that time I upgraded from VFP-6 to 9 and most everything worked without a burp.

Re: AVFP and Interesting link

+1 From the article: "If you needed to parse the lines, then VFP is quite slow on string operations, compared to C#." Really?!?? [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.lea

Re: AVFP and Interesting link

No. There's lies, damned lies, and then there's benchmarks. I've seen benchmarks showing VFP really slow parsing text files, because the coder had never seen _MLINE nor knew how to use it. VFP can be wickedly fast if properly tuned. As George Goley pointed out, all you need to do is take out the s

Re: AVFP and Interesting link

I've read a lot time ago that this is true because C# string optimizations where made by part of the Fox Team :) So yes, I believe that the same people that made VFP Great can enhance some parts and implement them on another language. Edit: Found some old articles: http://

Re: VFP top level menu on tablets and phones

On 11/04/2016 14:03, Dave Crozier wrote: Peter, Yes, I used a top level form to control access to sub forms and leave it floating or minimised. It seems to work well, also I subclassed the buttons so you can freely change their style etc. Users seem to love it as it is very simple and I have a

Re: AVFP and Interesting link

On 2016-04-09 23:34, AndyHC wrote: I was browsing through the AVFP** discussion site and came across this link re. Foxpro speed: http://stackoverflow.com/questions/34667084/c-sqlite-performance-vs-foxpro-for-importing-files ** anyone using it? I've got a test setup running fine locally and on G

RE: VFP top level menu on tablets and phones

Peter, Yes, I used a top level form to control access to sub forms and leave it floating or minimised. It seems to work well, also I subclassed the buttons so you can freely change their style etc. Users seem to love it as it is very simple and I have added the ability to drag "preset button sho

Re: ShellExecute window size ignored

Another point of view to consider here is that, in using ShellExecute, you're yielding to Windows to open the PDF in the registered application. It may be the default Reader in some OS. It may be FoxIt, as someone's already mentioned. It may be the full Adobe Suite, if someone has that installed. O

Re: VFP top level menu on tablets and phones

On 08/04/2016 13:04, Dave Crozier wrote: BIG BUTTONS are the answer Peter. We tried the same thing with our apps and it was a dismal failure. Then we had a rethink and just modified the user interface to use buttons that you just can not mistake!! Funnily enough lots of the people using the de

RE: ShellExecute window size ignored

Thank you Fernando -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Fernando D. Bozzo Sent: 11 April 2016 13:35 To: profoxt...@leafe.com Subject: Re: ShellExecute window size ignored Hi Paul: The problem is that Adobe Reader is not a normal applicat

Re: ShellExecute window size ignored

Hi Paul: The problem is that Adobe Reader is not a normal application, and do not respect normal messages. I've found an awful hack, but seem to work: http://superuser.com/questions/640174/how-to-start-adobe-reader-with-window-maximized?newreg=e8665170ca67456285b056122e43653d 2016-04-11 13:2

RE: ShellExecute window size ignored

Oh, and the hndWin parameter is numeric Dave -Original Message- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Dave Crozier Sent: 11 April 2016 13:27 To: ProFox Email List Subject: RE: ShellExecute window size ignored Paul, I don't use Adobe it is a pain but the equivalent

RE: ShellExecute window size ignored

Paul, I don't use Adobe it is a pain but the equivalent runs with FoxitReader PDF reader. Set up cParams to be path to the PDF to open. DECLARE INTEGER ShellExecute IN shell32.dll ; INTEGER hndWin, ; STRING cAction, ; STRING cFileName, ; STRING cParams, ; STRING cDir, ; INTEGER

RE: ShellExecute window size ignored

Thanks but I tried that and it still didn't work - it was another developer who wrote the code and assigned a numeric value to lcCallingWindow instead of lnCallingWindow -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Fernando D. Bozzo Sent: 11 Apr

Re: ShellExecute window size ignored

Hi Paul: lcCallingWindow should be numeric, and normally is 0. Try if this makes any difference El 11/4/2016 11:49 a. m., "Paul Newton" escribió: > Hi all > > I am trying to view a PDF in a maximized window > > ShellExecute(lcCallingWindow, "Open", lcFileName, "", "", 3) > > The last parameter

ShellExecute window size ignored

Hi all I am trying to view a PDF in a maximized window ShellExecute(lcCallingWindow, "Open", lcFileName, "", "", 3) The last parameter _should_ force the application window to be maximized but it doesn't :( The default application for PDFs on my system is Adobe Reader XI V11.0.09 and I am ru