VFP-64Bit

[alisaif]

Hi,

Is it safe to use VFP-64 Bit.

[link ]

http://www.baiyujia.com/vfpadvanced/f_vfpa_about.asp

[/url]

Please advise.

Thanks

Saif

 

[Olaf Doschke]

It's illegal. Decompiled, recompiled for 64bit.

thread184-1752782

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.

 

[alisaif]

Thanks Mr.Olaf for the advice.

Saif

 

[Michael42]

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

 

[Mike Lewis]

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

 

[Olaf Doschke]

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.

 

[Jockey4]

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)

 

[Olaf Doschke]

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.

 

[dkean4]

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

 

[Nigel Gomm]

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

 

[Olaf Doschke]

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.

 

[dkean4]

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:

Thisform.Refresh

FOR I = 1 TO 1000
	ThisForm.Move(I*3,I*3)
NEXT

Add this code to ThisForm.Click

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

 

[Scott24x7]

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

 

[Olaf Doschke]

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 [tt]lnPos = IIF(t>1, 3000, 3000*t^2)[/tt] 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.

 

[dkean4]

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

 

[Olaf Doschke]

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

 

[dkean4]

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.

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

 

[Olaf Doschke]

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:

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

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

 

[dkean4]

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

 

[Olaf Doschke]

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.