VFP-64Bit VFP-64Bit alisaif (ISP) (OP) 20 Mar 17 05:12 Hi, Is it safe to use VFP-64 Bit. http://www.baiyujia.com/vfpadvanced/f_vfpa_about.asp Please advise. Thanks Saif RE: VFP-64Bit Olaf Doschke (Programmer) 20 Mar 17 06:15 It's illegal. Decompiled, recompiled for 64bit. thread184-1752782: 64-Bit VFP You don't need it, VFP9 runs on 64bit Windows in its 32bit subsystem. Any rumor about a pure 64bit Windows has not yet become even 1% truth, and once that would be the case you don't need to go that Windows version and could run todays Windows virtualized. Look at how long FPDOS apps run, though there is no DOS support from MS today. Stay off that. Bye, Olaf. RE: VFP-64Bit alisaif (ISP) (OP) 20 Mar 17 09:42 Thanks Mr.Olaf for the advice. Saif RE: VFP-64Bit Michael42 (Programmer) 31 Mar 17 14:57 The developer for VFP-64 does seem to be making an earnest effort. He has multiple updates in 2017. There are advantages of using 64-bit software especially if you deal with high OLTP or huge databases. If you will only ever be using small to medium sized databases I concur the 32-bit should be OK for you. Still, it would be nice to see a 64bit VFP mature and gain support. Thanks, Michael42 RE: VFP-64Bit Mike Lewis (Programmer) 31 Mar 17 16:21 In the thread that Olaf mentioned, we had a long discussion about the legality of this product and other issues related to it. I don't want to resurrect that discussion here, not least because I was in a minority on that occasion. But just be aware of the points that were raised in that earlier thread. Mike __________________________________ Mike Lewis (Edinburgh, Scotland) Visual FoxPro articles, tips and downloads RE: VFP-64Bit Olaf Doschke (Programmer) 1 Apr 17 11:10 Yes, you only measure "earnest" effort by how much time the developer invests into progress. If the base of this version is a decompilation it's illegal in most jurisdictions and even in those which have a loose copyright law, American copyright laws apply international, you bet on MS not suing anybody using this software. What the developer does here is renovating a house he doesn't own and sell it to you. All the renovation might be fine and if it would be an open source base worth the claimed prices, but I don't only see this as illegal, it's also outrageous to do this. Besides I don't see the 64bit version promising larger DBFs, just being a 64bit process you can access more memory, but if the binary composition of a dbf file, which for example uses 32bit (4 bytes) for pointers into the fpt in MEMO fields only, you can only higher that to 64bit pointers by using more bytes for each memo field or use the numbers in 32bit as offsets*N to get up to N*2GB, thus also only pointing to file positions in N byte distances. But also that, while not changing the size of the pointer, can't be shared access with a legacy application using the same DBFs. So this would need a specific new DBF structure, and as straight forward as that would work will not be compatible. Besides that pointersize problem, even though drives are larger and bus speeds are much higher today, I personnaly think any file >1GB already is a performance mess in comparison with a good server. Sequential access - fine, no matter what file size, but random access? Only after you know which recno you want (from index seeks), you can FSEEK to that point very fast again no matter how large the file. But the binary tree indexes CDX tags store become less efficient than what MSSQL and other database servers use and allow on top of using caching and statistics in a more efficient way than VFPs caching. If you want to go big datawise, go server. Bye, Olaf. RE: VFP-64Bit Jockey4 (Programmer) 5 Apr 17 16:43 Olaf, I agree, but on the other hand, the developper has fixed a number of bugs which now exists in VFP9, one should consider to make use of his "VFP10" application if you have troubles with any of the fixed bugs. Surely it is, if at all, illegal to make use of his 'VFP10', 100% illegal if you dont't have a legal VFP9 installed. Regards, Jockey(2) RE: VFP-64Bit Olaf Doschke (Programmer) 5 Apr 17 18:20 I don't continue with VFP, so the question does not really arise. If I would, I would have problems using 32bit drivers and DLLs of which there are no 64bit equivalents. I have to say I don't really know whether it is legal to use a derived and fixed product because I own VFP9. Like the comparison was, you buy a renovated home the renovator doesn't own, that you own it makes it better, but I think alone decompilation is illegal. I know Mike has a made a point about that with reasons speaking for such a reuse, if the original vendor does not exist anymore. But that's not the case with Microsoft. If Microsft would make an official public statement about this, that would be fine, and then the work would be ok and worth paying for, but Microsoft explicitly chose not to make VFP open source as parts of it are used in MSSSQL Server (I assume), at least in other MS products. What remains is that "it's also outrageous to do this.", to me. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 7 Apr 17 15:03 The annoying part in VFP 32bit is its UI response. DB access can be solved with RAM drives and a good network backbone, but for some forsaken reason the UI is a dog! VFP is zippy as could be until UI and display of multiple objects come up in high numbers or a page refresh is invoked on a complex screen. What the hell are they doing with the UI engine... Do they send requests to MS on Snail mail to get a permission to act? Is it the binding being rewired??? I used to get a better response with my own graphics module in FoxPro 2.5, years back. LockScreen is great to eliminate multiple separate changes from refreshing multiple times, but it would be so nice if the screens could be composed faster and one could see moving objects without staggering and looking like the PC is about to die. For that alone, I would gladly pay twice the price of VFP. I have resorted to playing videos to animate objects in VFP. What a circus. Somebody tell that developer to solve that problem please. By the way, guys, have you ever been in a hurry and clicked+released on the header of a project and quickly moved your mouse away to suddenly see the project disappear and land in Europe? What is that about? Slow mouse driver, or the very same issue with the UI? That one gets me every time. AIIIIEEE CARRAMBA! Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Nigel Gomm (Programmer) 7 Apr 17 16:37 Dennis, i'm not seeing any of the problems you describe with a VFP app's UI.... .... do you have a lot of code in your controls' .refresh events? use set coverage to see what's happening. e.g. set coverage to c:\temp\cover.log in a form's .load event. Then set coverage to in its .destroy event. Open the form, do what you do then close the form. Open cover.log in notepad and look at the activity and the time each line of code takes. n RE: VFP-64Bit Olaf Doschke (Programmer) 7 Apr 17 18:18 I don't know what you talk about. Give concrete samples. The latest thread about a slowdown I remember was about a form having many containers and no focusable control. So avoid that. Aero was a problem, nowadays is less of a problem and if, only in the IDE. I second Nigel about coverage logging, it's the final truth about what code runs. You also should take event tracking into account, as it can also track events happening with their basic native behaviour, when they have no code and so won't appear in a coverage log. There is a gap though, some events need code to come up in an event tracking and then of course also appear in the coverage log. Overall, that's not such a bug bummer, you typically find out what takes long and might be surprised about some code causing reentrance of events, if you do too much, as Nigel assumes, this may happen in a refresh of some detail control retriggering a whole form refresh, causing a cascading effect. Yes, things like the lockscreen property help a lot, but also point out you might cause to much cascading of events, which takes much longer, if it happens while screen refreshing is not locked. 64bit doesn't change any of this. WinForms is the base technology and stays the base technology, 2D graphics acceleration has not advanced and there is not much to advance there, but faster graphic bus speeds. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 10 Apr 17 12:16 Create a new form 500 x 350 pixels Put in a Label as title "This that and the other" Add a TestBox and make it wide Add an EditBox and stretch it to occupy most of the space below the TextBox Add this code to the Activate event: CODE --> ThisForm.ActivateThisform.Refresh FOR I = 1 TO 1000 ThisForm.Move(I*3,I*3) NEXT Add this code to ThisForm.Click CODE --> ThisForm.ClickThisForm.Activate Run it and keep clicking on the form. And please don't tell me that it is smooth. I have an NVIDIA GEFORCE GTX 950, which is not a bad video card, with 2 Gigs of memory, and the transition is crappy. It staggers and stutters. But with a high-performance card, the staggering is equally spaced, so you imagine that all is honkey dory. It is not. This is a very light form and it has at least 3 graphic issues. If you want to see it better change the background of your VFP screen to the color black and try again. And heaven forbid that you should have another VFP form under that form. That leaves a trail until the last image is painted, at which time it is refreshed. I play with graphics and images a lot. This is a given with VFP. Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Scott24x7 (Programmer) 10 Apr 17 12:19 Dennis, that's interesting, but does 64-bit VFP solve that issue? Best Regards, Scott ATS, CDCE, CTIA, CTDC "Everything should be made as simple as possible, and no simpler." RE: VFP-64Bit Olaf Doschke (Programmer) 10 Apr 17 14:42 Well, that's not how to move a form. If you want a behaviour with a certain timing, make it depend on seconds() past an initial seconds() value. Aside if that as I said modern graphics cards don't contribute anything new to 2d acceleration, VFP will not profit of any 3d cpabilities of a gtraphics card. If you want a very good VFP behaviour find something with best 2d accelaration. Also VFP will not draw using Direct2D, but GDI+, there never will be anything improving that but mere CPU enhancements. I second Scotts question: Does 64bit VFP solve that? Does it render forms without going through GDI+? Does it make use of Direct2D? It runs quite smooth on my PC, which only has a AMD Radeon R5 310, but too fast to be really smooth. For a smooth animation without shutter effects what's most important is having an animation rate in sync with screen refresh rates, any other too fast animation is causing several states of the form during one refresh of the desktop and that looks bad. You could try with a timer set to 40ms interval, giving 25 fps and setting a position like lnPos = IIF(t>1, 3000, 3000*t^2) where t is time in seconds after the click time t0=Seconds(). Only enable the timer after a start value t0 is Seconds() and compute t=Seconds()-t0 to compute the position. Let the timer disable itself, if t>1. Also no need to refresh THISFORM, what needs refresh is _SCREEN. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 10 Apr 17 14:56 That was my wonder. I was talking about the standard version of VFP 9.0 SP2 I think that window refresh in VFP is designed to refresh not only the graphic layers but the bindings and other non-visible elements, then text rendering etc... If it is the WinForms itself, as Olaf said, then WinForms needs to be optimized BIG time. Look at the browsers and the smooth transitions of its elements. Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Olaf Doschke (Programmer) 10 Apr 17 15:10 Well, mainy thisform.refresh() refreshes it's content, bu what ontent changes, when you move a form? The content of _screen, not the content of Thisform..., so you would refresh _screen, not thisform. Refresh only is an inner refresh and also redraws overlapping and in front forms. Very generally: Yes, Winforms never was made with form animations in mind. WPF forms have a storyboard, just to name one animation specific property of WPF forms. A lot is possible there, but also doesn't ook smooth when done too simple. For example also look back about something as simple as a smoothly growing progress bar in my own thread184-1737918: Refreshing form smoother via Cls than Refresh. Why?, wheree I already start stating Cls() is smoother than Refresh(), and finally find out it's best to avoid painting too often by storing Seconds() in a .lastpaint property and suppress a redraw, If Seconds()-Thisform.lastpaint<1/50, draweing more then 50 times a second does not lead to a smoother animation but to shutter and flicker effects. Smooth animations are not about the most often redraw, but drawing at the right place and time, if you redraw too often taking a shot&freeze frame you rather will have a form drawn and cleared within the same frame, thus looking shuttered. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 10 Apr 17 16:09 Olaf, The timer makes it worse, that's why I did not send you that version. Try it! It does not render every image. Only occasionally does it complete a refresh. It staggers, hic-ups and what not. At least this way the next instruction cannot fire until its predecessor has completed. With the timer it fires whether finished or not. Instead of the timer, use WAIT "" TIMEOUT 0.020, but you must have a TextBox and an EditBox on your form to see the effect. This guarantees that you will not retrigger before the form was fully repainted. Put this code in your Click event of the Form and study the problem. CODE --> Formthisform.Refresh FOR I = 1 TO 200 thisform.Refresh WAIT "" TIMEOUT 0.020 ThisForm.Move(I*4,I*4) NEXT Now you can see the problem clear as could be. The form is repainted and the label is refreshed immediately with it. But the TextBox and the EditBox take more time to repaint. And they are not repainted simultaneously. You can see the delay between them. You may need to play with the delay to get to see this, depending on the performance of your PC and Graphics card. On my QuadCore and high-performance card, it is clear as daylight. There is also no question that the Graphics output of VFP (if it is GDI+) is buffered. That is what causes the anomalies. And if you have a complex form, heaven help you. Moving the form in real time stinks no matter what and so does moving objects on the form. The fills, on lesser PCs, remind me of the early 90s fills, where you can see partial fills flashing like staircases. And you are right that a better Graphics card makes it look better, Olaf. But it is far, far from the transitions of CSS3 or jQuery, Raphael etc... Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Olaf Doschke (Programmer) 10 Apr 17 17:32 Yes, of course this stutters, as you don't give Windows any chance to apply it. The core thing running in windows is multiple processes with each multiple threads and a management of what slices of time are assigned to which processes. If you want something to come into effect, you got to let it happen. There has to be time for the OS and grapics to do the Move. The core thing making the progress bar smooth was to not allow more than 25 paint events to happen per second. Wait is not a good thing to do, DOEVENTS is what is necessary. You also still fail to see that the SCREEN or even the Windows DESKTOP needs a refresh to redraw the moved window in it. If you do such a tight loop you don't give anything a chance to react. Most eveything you do in regard of changing a form position or position of objects within or text contained will only be queued in Windows event queueue, you got to give that a chance to work. Do this: CODEFOR I = 1 TO 200 DOEVENTS ThisForm.Move(I*4,I*4) NEXT Or to make this an animation going with about .02 seconds per frame: CODEDECLARE Sleep IN WIN32API integer nMilliseconds thisform.Refresh FOR I = 1 TO 200 _screen.cls() DOEVENTS Sleep(20) ThisForm.Move(I*4,I*4) NEXT a) You don't need a refresh to let a moved form be drawn at its new position, but force a repaint of the _screen. b) Wait Window is a really bad choice as itself creates a window (guess what it's named? wait window), even when you use "" as its display text you still go through all window creation, the form you animate is losing focus and later is reactivated, you cause it to repaint multiple times. For a short wait use Sleep(), if you only want to let a process sleep and use DOEVENTS most of the time you just want things to happen. Here I do both, as sleep alone doesn't trigger enough. In this case you better do DOEVENTS without the FORCE option, as you don't care about the whole windows events, only your own. In regard of getting a smooth animation you'd need to bind _screen paint events and suppress them, if they happen too frequent, that'll make animations smoother. Besides as I already proposed earlier calculating positions by passed time will give you a better repeatable animation style than doing things "as fast as they can be done". I understand you just do this to demo some unsmooth behaviour, but come on, don't do silly things to prove something, that doesn't make any point. Doing silly code makes silly things happen. First silly thing is doing something long running in a click event. You freeze the event queue because you yourself don't return from an event. This doesn't only suggest using DOEVENTs to cope with this, it's the only chance, no Wait Window will really help here. Click is an event and you don't put anything long running in there, you don't animate using a loop, but setting positions in a timer event, just one position of the whole animation, the loop is done by having a timer interval. Besides all that, Foxpro isn't any animation software anyway, not even Windows itself. Animated windows are a WPF feature, not a winforms feature, never was, never will be. Rememember Win 3.1/3.11, how minimized forms where "resurrected" by drawing some lines indicating form growth and only finally drawing the form? To lead the users eye, that also is sufficient. If you want to force it, then do so, but then use something more modern than Foxpro or even than Windows. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 11 Apr 17 13:53 Olaf, The point of the refresh in the loop was to accentuate the slow repainting of the Text and Edit boxes. I would never use it in motion. The Sleep() API call is new to me, so thank you for that. It is better than WAIT WINDOW. So, it is clear that VFP was not designed for animation. I called it "Slow UI" That was my complaint to start with. Thank you for the clarifications, Olaf. Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Olaf Doschke (Programmer) 11 Apr 17 14:11 I don't know what you refer to with slow repainting of text and editboxes. Seems your graphics drivers arenot caring about 2D at all. And again, you can't assume Move() will move a form right away, it just triggers events, Winforms are all event driven. WM_PAINT is a message sent to a hwnd causing a form to paint, WM_SETTEXT is a message and WM_MOVE moves a form. VFP will only cause such messages to be added to the event queue and they can only happen, after you finish Click, you should know that. Well, you even don't know one of the simplest API calls - Sleep. The main "secret" is doing DOEVENTs. With click you ARE in an event, and no other event happens, before you end your own click event code or trigger further events to happen via DOEVENTS. Sleep is not the secret here, you can remove the sleep and only DOEVENTS and that'll cause a smooth rendering of the moved form, already and faster. And all this has nothing to do at all with 64bit CPUs, this has much more to do with your graphics card drivers and how it hooks into GDI+ or if it offers any hooks to GDI+ at all. 3D graphic cards care about their integration in Direct3D, Direct2D, DirectX, OpenGL, but the more expensive, the more likely GDI+ has no graphic card acceleration at all and does all software rendering of 2D graphic commands as VFP uses to draw its controls. For running foxpro apps, you can be far better off with an office graphics card than a gaming graphics card. This is the end point for me, you already hijacked this thread for a totally different topic and you still didn't get what I explained, I give up at this piont. Bye, Olaf. RE: VFP-64Bit dkean4 (Programmer) 11 Apr 17 15:54 Olaf, I did get the point about DOEVENTS. It is definitely the central point and I did many tests with it to find the optimum. Sorry that I did not make a clamor on that point. It was so obvious that I went on to something I did not know, before. Sleep(n) was very interesting to me. So, if not knowing, that VFP API, makes me into a neophyte, "so be it". It is not my interest to maintain the illusion that I know everything. In fact, I am here because I do not know everything and I am very appreciative of your, Mike's and all the other guy's help. I wish I had taken advantage of using your forum in my earlier days. All in all, you have affirmed my original point that VFP is not great in moving forms and objects in 2D. However, you have still improved my insight into how to tweak it some more. It is always a pleasure to hear from Olaf. Maybe you could look at it from my point of view. I get excited about things I do not know. Now I can improve some of my former attempts at making a smooth entry of a form, starting from total transparency and moving in from the center of the screen to the last location the form was parked. Crazy, maybe, but I have my own ticks, you know. So, if I forgot to affirm your main point, my apology for that. Nevertheless, I highly appreciate your patience tenacity and your incredible depth of understanding. You were very helpful to me here, Thank you for that, Olaf. Dennis Kean Simplicity is the extreme degree of sophistication. Leonardo da Vinci RE: VFP-64Bit Olaf Doschke (Programmer) 11 Apr 17 16:03 This is Windows API, not VFP API, if it would be VFP, you would not need to DECLARE this DLL function. Sleep is one of the most basic Windows API functions, it was about the first I learned, maybe ShellExecute was first. Anyway, some day you have to decide whether you really like VFP or not, because most of the time you want or need to use something external to VFP. As you are so fond of very low level stuff, you rather should use C/C++, this really would be for you, the core language is not capable to do much, but there are a vast number of libraries for everything. Still much more than for C#, you can also link libs and not need to do late binding as VFP with COM or it's DECLARE. Bye, Olaf. RE: VFP-64Bit Scott24x7 (Programmer) 12 Apr 17 02:47 This is WAY off topic now... should open another thread. Best Regards, Scott ATS, CDCE, CTIA, CTDC "Everything should be made as simple as possible, and no simpler." RE: VFP-64Bit foxwizard (Programmer) 21 May 17 23:58 Guys, I played with this VFP 10 64-Bit and it really converted my application to a 64-Bit version. I also noticed that my application worked more faster than when it was in a 32-bit version. The only downside is I have to remove a few of my 32-Bit ActiveX and that there are no 64-Bit ActiveX available so far although we can use third-party ones according to the author. RE: VFP-64Bit Jockey4 (Programmer) 22 May 17 14:42 Foxwizard, your application 64-bit, have you compiled it to an exe? Have you deployed that exe to an other or a virtual pc? and which runtimes did you had to install on your other pc? Regards, Jockey4 RE: VFP-64Bit mgagnon (Programmer) 22 May 17 17:12 Foxwzard I see 2 things posted on the website 2014/11/1 1, The DotNet ActiveX Controls (64-bit) ok. ************************************************** 2014/9/10 1, The Microsoft Forms 2.0 ActiveX Controls (64-bit) ok. Mike Gagnon If you want to get the best response to a question, please check out FAQ184-2483: How to get the best response from the forum first. RE: VFP-64Bit foxwizard (Programmer) 24 May 17 09:37 Jockey4, Yes I compiled my application to an exe and tested it on my PC and it was working fine. No changes made to my application except that I had to remove the 32-Bit ActiveX and comment the codes that uses them. I have not deployed my application yet but to check if your application is a 64-Bit one, simply run your application and then check it using task manager. There is a column platform in details which tells you if an application is a 32-Bit or 64-Bit. If you can't find the platform, just right click the header then select columns, look for platform and check it. Thanks mgagnon, I will check them.