FiveTech Software tech support forums

New game.

look for the differences

fwh 12.17



fwh 11.18

... save ()". Here too, problems have arisen because in general this may work but I have to configure and save each field because there could be differences with specific functions it is difficult to explain. 5) up to now with James I have not seen a working test but only oCustomers := TCustomers():new()  ...

... be true that more complex applications will not work out. A couple of years ago I tested out FiveMac. It's a great idea, but there are essential differences in the operating systems, and because of that, many advanced windows features in FWH could not be ported to the Mac. Perhaps the same ends ...

... mobile versions: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/52bef792-daa4-41ed-878b-bf22666609b2/shcreatemenubar-differences-in-windows-mobile-653?forum=vssmartdevicesnative It is not a FWPPC issue. It is a Windows CE bug :-(

To All Generally I prefer BCC .. and Enrico is correct ... BCC creates a smaller .exe .. again, not a big deal.... but I like the C++ Command line concept. I work also for a small computer shop and when I am not writing code .. I help out with the technical aspect of the retail business. I have stat...

I generally find speed is not a real time issue, but I have noted that doing an Index on a pure Win 10 machine version an Apple running Parallels with Win 10, the Apple is MUCH faster. I have no idea why.

Tim, I made some speed compare test between BCC 7.30 and MSVC 2017 and found the former much faster (I'm referring to dbf and index operations). And as a bonus, BCC generates smaller EXEs. That's why I'm using BCC.

EMG

I have to admit ... I don't understand why all the different compilers. I build all code with two options: 1). Older xHabour ( .com version ) with xBuilder ... 2). Preferred option of Visual Studio 2017 Community edition ( MSVCC ) plus Harbour I only use #1 for those who are using ADS Version 7 or 8...

Thanks, this is no problem to respect!
But i test also ::move(,,nWidth,nHeight) or ::SetSize( nWidth, nHeight). This methods also give differences. (in VCC also the 10 Pixels to small in both directions)

In any case, it is not a good idea to use oDlg:nHeight or oDlg:nWidth for calculating relative position of controls, because these datas give external dimensions. Not client area dimensions. I personally recommend this way: local nDlgWidth := 400 local nDlgHeight := 200 DEFINE DIALOG oDlg SIZE nDlgW...

In fact, ::nWidth()/::nHight()/::nWidth/::nHight/::GetRect() differs on both compilers and should not used to calculations for controls!?

It is true that the external dimensions of the dialog differ by 10 pixels (both height and width). But the client rect of the dialog is exactly the same in both and also same as the coordintates specified by us while creating the dialog. So if we position the controls either with absolute coordinate...

Günther I tested your code with Bcc73\xHarbour and MSVC2017\xHarbour on Windows 10 Spring Creator Pro 64 bit and got the same result ... here is your code: #Include "FIveWin.ch"function dlg_test()local oDlg, oFont, oMemo, oFile, oBtnok, oBtncancel, cFile := space(50), uTemp...

But the client rect is identical in both cases.