[Harbour] command syntax for multi weindows
harbour now support multiwindows
clipper user are command driven
so i proposal a command syntax that will be stantard
a good idea will be a common syntax common to minigui, fivewin or
xbase, visual fox
I think something like
#inglude "harbwind"
define window main width 400 height 400 clientarea
@ 10,10 say "test" get test
end window
activate window main
read
#include "FiveWin.ch"
function Main()
local oButton, oWnd, hBitmap
DEFINE WINDOW oWnd TITLE "ViaCoral - Skinned All Application Buttons!!"
ACTIVATE WINDOW oWnd MAXIMIZED
#include "minigui.ch"
Function Main
DEFINE WINDOW Win_1 ;
AT 0,0 ;
WIDTH 400 ;
HEIGHT 200 ;
TITLE 'Hola Mundo!' ;
MAIN
END WINDOW
ACTIVATE WINDOW Win_1
Return
visual fox pro oop syntax
loForm = CREATEOBJECT("HiForm")
loForm.Show(1)
DEFINE CLASS HiForm AS Form
AutoCenter = .T.
Caption = "Hello, World"
ADD OBJECT lblHi as Label WITH ;
Caption = "Hello, World!"
ENDDEFINE
visual fox pro command syntax
DEFINE WINDOW HelloWorld FROM 1,1 TO 2,10 TITLE "Hello World"
ACTIVATE WINDOW HelloWorld
xbase syntax based on xppdialog that is already implemented in gtwvg
#include "Gra.ch"
#include "Xbp.ch"
#include "Appevent.ch"
PROCEDURE AppSys
LOCAL oDlg, oXbp, aPos[2], aSize
/*
* Get size of the desktop to display the application window centered
*/
aSize := SetAppWindow():currentSize()
aPos[1] := (aSize[1] - 640) / 2
aPos[2] := (aSize[2] - 400) / 2
oDlg := XbpDialog():new( SetAppWindow(), , aPos, {640,400}, , .F.)
oDlg:title:= "GUI Demo"
oDlg:taskList := .T.
oDlg:icon := 1
oDlg:close:= {|| AppQuit() }
oDlg:create()
oDlg:drawingArea:SetColorBG( GRA_CLR_WHITE )
SetAppWindow( oDlg )
oDlg:show()
RETURN
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10267] trunk/harbour
Revision: 10267 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10267&view=rev Author: druzus Date: 2009-02-14 09:44:23 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 10:49 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/vm/memvars.c % small optimization in __MVSAVE() Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/source/vm/memvars.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10268] trunk/harbour
Revision: 10268 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10268&view=rev Author: vszakats Date: 2009-02-14 12:18:24 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 13:17 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak * make_gcc.mak * common.mak * utils/Makefile + Added hbmk to make systems. * utils/hbmk/hbmk.prg + Update. Second pass, it's now ready for testing. I've only tried with BCC yet. Please test and if possible update internal setup for various platforms/compilers. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/common.mak trunk/harbour/make_b32.mak trunk/harbour/make_gcc.mak trunk/harbour/make_vc.mak trunk/harbour/utils/Makefile trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10269] trunk/harbour
Revision: 10269 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10269&view=rev Author: vszakats Date: 2009-02-14 12:26:53 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 13:25 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg + Added linux/owatcom, os2/icc support. (completely untested) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10270] trunk/harbour
Revision: 10270 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10270&view=rev Author: vszakats Date: 2009-02-14 13:26:30 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 14:23 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg - Added support for -o option for win/bcc32. - tests/hbmk_vc.bat - tests/hbmk_b32.bat + contrib/hbmysql/utils/hbmk.bat - contrib/hbmysql/utils/hbmk_b32.bat - contrib/hbmysql/utils/hbmk_vc.bat + contrib/hbmysql/tests/hbmk.bat - contrib/hbmysql/tests/hbmk_b32.bat - contrib/hbmysql/tests/hbmk_vc.bat + contrib/hbct/tests/hbmk.bat - contrib/hbct/tests/hbmk_b32.bat - contrib/hbct/tests/hbmk_vc.bat + contrib/hbodbc/tests/hbmk.bat - contrib/hbodbc/tests/hbmk_b32.bat - contrib/hbodbc/tests/hbmk_vc.bat + contrib/xhb/tests/hbmk.bat - contrib/xhb/tests/hbmk_b32.bat - contrib/xhb/tests/hbmk_vc.bat + contrib/hbtpathy/tests/hbmk.bat - contrib/hbtpathy/tests/hbmk_b32.bat - contrib/hbtpathy/tests/hbmk_vc.bat + contrib/hbmsql/tests/hbmk.bat - contrib/hbmsql/tests/hbmk_b32.bat - contrib/hbmsql/tests/hbmk_vc.bat + contrib/hbsqlit3/tests/hbmk.bat - contrib/hbsqlit3/tests/hbmk_b32.bat - contrib/hbsqlit3/tests/hbmk_vc.bat + contrib/hbole/tests/hbmk.bat - contrib/hbole/tests/hbmk_b32.bat - contrib/hbole/tests/hbmk_vc.bat + contrib/hbmzip/tests/hbmk.bat - contrib/hbmzip/tests/hbmk_b32.bat - contrib/hbmzip/tests/hbmk_vc.bat + contrib/hbapollo/tests/hbmk.bat - contrib/hbapollo/tests/hbmk_b32.bat - contrib/hbapollo/tests/hbmk_vc.bat + contrib/hbfbird/tests/hbmk.bat - contrib/hbfbird/tests/hbmk_b32.bat - contrib/hbfbird/tests/hbmk_vc.bat + contrib/hbziparc/tests/hbmk.bat - contrib/hbziparc/tests/hbmk_b32.bat - contrib/hbziparc/tests/hbmk_vc.bat + contrib/hbnf/tests/hbmk.bat - contrib/hbnf/tests/hbmk_b32.bat - contrib/hbnf/tests/hbmk_vc.bat + contrib/hbcurl/tests/hbmk.bat - contrib/hbcurl/tests/hbmk_b32.bat - contrib/hbcurl/tests/hbmk_vc.bat + contrib/rddsql/tests/hbmk.bat - contrib/rddsql/tests/hbmk_b32.bat - contrib/rddsql/tests/hbmk_vc.bat + contrib/hbhpdf/tests/hbmk.bat - contrib/hbhpdf/tests/hbmk_b32.bat - contrib/hbhpdf/tests/hbmk_vc.bat + contrib/rddado/tests/hbmk.bat - contrib/rddado/tests/hbmk_b32.bat - contrib/rddado/tests/hbmk_vc.bat + contrib/gtwvg/tests/hbmk.bat - contrib/gtwvg/tests/hbmk_b32.bat - contrib/gtwvg/tests/hbmk_vc.bat + contrib/hbpgsql/tests/hbmk.bat - contrib/hbpgsql/tests/hbmk_b32.bat - contrib/hbpgsql/tests/hbmk_vc.bat + contrib/rddads/tests/hbmk.bat - contrib/rddads/tests/hbmk_b32.bat - contrib/rddads/tests/hbmk_vc.bat + contrib/hbclipsm/tests/hbmk.bat - contrib/hbclipsm/tests/hbmk_b32.bat - contrib/hbclipsm/tests/hbmk_vc.bat + contrib/hbfimage/tests/hbmk.bat - contrib/hbfimage/tests/hbmk_b32.bat - contrib/hbfimage/tests/hbmk_vc.bat + contrib/hbgd/tests/hbmk.bat - contrib/hbgd/tests/hbmk_b32.bat - contrib/hbgd/tests/hbmk_vc.bat + contrib/hbmisc/tests/hbmk.bat - contrib/hbmisc/tests/hbmk_b32.bat - contrib/hbmisc/tests/hbmk_vc.bat + contrib/hbgf/tests/hbmk.bat - contrib/hbgf/tests/hbmk_b32.bat - contrib/hbgf/tests/hbmk_vc.bat + contrib/hbtip/tests/hbmk.bat - contrib/hbtip/tests/hbmk_b32.bat - contrib/hbtip/tests/hbmk_vc.bat + contrib/hbwin/tests/hbmk.bat - contrib/hbwin/tests/hbmk_b32.bat - contrib/hbwin/tests/hbmk_vc.bat + contrib/hbvpdf/tests/hbmk.bat - contrib/hbvpdf/tests/hbmk_b32.bat - contrib/hbvpdf/tests/hbmk_vc.bat + contrib/hbbtree/tests/hbmk.bat - contrib/hbbtree/tests/hbmk_djg.bat - contrib/hbbtree/tests/hbmk_b32.bat - contrib/hbbtree/tests/hbmk_vc.bat + contrib/hbcrypt/tests/hbmk.bat - contrib/hbcrypt/tests/hbmk_b32.bat - contrib/hbcrypt/tests/hbmk_vc.bat + contrib/hbssl/tests/hbmk.bat - contrib/hbssl/tests/hbmk_b32.bat - contrib/hbssl/tests/hbmk_vc.bat + contrib/hbwhat/tests/hbmk.bat - contrib/hbwhat/tests/hbmk_b32.bat - contrib/hbwhat/tests/hbmk_vc.bat - source/rdd/usrrdd/example/hbmk_b32.bat - source/rdd/usrrdd/example/hbmk_vc.bat % Updated for new hbmk.bat and hbmk.exe. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk/hbmk.prg Added Paths: --- trunk/harbour/contrib/gtwvg/tests/hbmk.bat trunk/harbour/contrib/hbapollo/tests/hbmk.bat trunk/harbour/contrib/hbbtree/tests/hbmk.bat trunk/harbour/contrib/hbclipsm/tests/hbmk.bat trunk/harbour/contrib/hbcrypt/tests/hbmk.bat trunk/harbour/contrib/hbct/tests/hbmk.bat trunk/harbour/contrib/hbcurl/tests/hbmk.bat trunk/harbour/contrib/hbfbird/tests/hbmk.bat trunk/harbour/contrib/hbfimage/tests/hbmk.bat trunk/harbour/contrib/hbgd/tests/hbmk.bat trunk/harbour/contrib/hbgf/tests/hbmk.bat trunk/harbour/contrib/hbhpdf/tests/hbmk.bat trunk/harbour/contrib/hbmisc/tests/hbmk.bat trunk/harbour/contrib/hbmsql/tests/hbmk.bat trunk/harbour/contrib/hbmysql/tests/
[Harbour] SF.net SVN: harbour-project:[10271] trunk/harbour
Revision: 10271 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10271&view=rev Author: vszakats Date: 2009-02-14 16:35:17 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 17:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg ! Fixes after testing with MSVC and MINGW both static and dynamic mode. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10272] trunk/harbour
Revision: 10272 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10272&view=rev Author: vszakats Date: 2009-02-14 18:47:59 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 19:50 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg + Added -strip/nostrip switch and implemented for GCC/GPP. + Added -trace switch to see executed commands. + Added negative switches: -std, -st, -nodebug + Added detection whether Harbour is installed in default system locations on *NIX systems. If it is, turn on shared libraries by default for all *NIX systems. + Added support for GT selection with -gt??? switch. (using .prg method, not .c as in hbmk bash script) + Added support for linux/gpp. ; NOTE: Some things still missing: - details of *NIX stuff, systems libs, switches, etc, etc. - -fullstatic not yet supported. - fmstat/nofmstat. It would be good to find a more easily manageable way to influence that. Current one is make system dependent and a bit hackish. - handling 3rd party libs. These should be supported by supplying proper parameter, and we can provide example scripts for these libs. Hard-wiring them into core Harbour is quite dangerous. - "MAIN" function override. I'd rather leave this out, and clear up the situation with entry procs. - gtsln and gtcrs support. - Watcom, OS/2, *NIX not tested. - Built-in support for our contribs. For clear separation of components contribs shouldn't be referred to in this core component. - Filtering foreign system libs passed on the command line for platforms not needing them. The goal is to be able to use as simple and _portable_ hbmk command lines as possible. - Support for POCC, DM. ; TODO: - Switch to portable command lines in hbmk.bat files. (Win9x will be supported again). - Remove bin/hbmk*.bat, bin/hbmk*.cmd, util/hbmake/*. - Cleanup on variable names in hbmk.prg. * tests/testid.prg * Minor cleanup. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/tests/testid.prg trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] WINAPI Functions .C Namespace
Hello, What we had decided on this topic? I mean, should we use .C file name based on .DLL or .H ? WAPI_ImageList_*() .C is ready and I have named it as c_commctrl.c. MSDN : Minimum DLL Version comctl32.dll version 6.0 or later Header commctrl.h Minimum operating systems Windows XP Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/WINAPI-Functions-.C-Namespace-tp22016531p22016531.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WINAPI Functions .C Namespace
Sorry Pritpal Bedi wrote: > > c_commctrl.c. > c_commctrl.cX w_commctrl.c Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/WINAPI-Functions-.C-Namespace-tp22016531p22016551.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WINAPI Functions .C Namespace
Hi Pritpal, The final agreement was on wapi_commctrl.c. Brgds, Viktor On Sat, Feb 14, 2009 at 9:23 PM, Pritpal Bedi wrote: > > Sorry > > > Pritpal Bedi wrote: > > > > c_commctrl.c. > > > > c_commctrl.cX > w_commctrl.c > > Regards > Pritpal Bedi > > -- > View this message in context: > http://www.nabble.com/WINAPI-Functions-.C-Namespace-tp22016531p22016551.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WINAPI Functions .C Namespace
Hi Viktor Szakáts wrote: > > Hi Pritpal, > The final agreement was on wapi_commctrl.c. > So make it crystal clear: MSDN .H ( Header File Name ) where function is declared will be ppstfixed to "wapi_?.c". Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/WINAPI-Functions-.C-Namespace-tp22016531p22017182.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Revision: 10273 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10273&view=rev Author: vouchcac Date: 2009-02-14 21:46:19 + (Sat, 14 Feb 2009) Log Message: --- 2009-02-14 13:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + harbour/contrib/hbwin/wapi_commctrl.c + Added WAPI_Image*() functions. * harbour/contrib/hbwin/hbwapi.h + Added more _par and _ret defines. ; The idea is to encapsulate Harbour API for WINAPI parameters and return values. Now wapi_commctrl.c looks very clean and easy to understand code. Also I have contained all those functions which are either not required on normal programming level OR I could not convert, with #if 0 / #endif blocks. But the header definitions are pulled from MSDN and have been kept alongwith. This ensures that whenever someone will try to implement them, all info will be handy. ; Please approve the above implementation so that I include these files in the build batches. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwapi.h Added Paths: --- trunk/harbour/contrib/hbwin/wapi_commctrl.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WINAPI Functions .C Namespace
> > > > > Hi Pritpal, > > The final agreement was on wapi_commctrl.c. > > > > So make it crystal clear: > > MSDN .H ( Header File Name ) where function is declared > will be ppstfixed to "wapi_?.c". I was thinking of the Library File Name where the given function is implemented. Reading back the mails, I'm not 100% sure what Francesco had in mind regarding this. We should hear him. Anyhow, for commctrl the header and lib names are the same, so we're fine until then. The implementations go to: wapi_*.c The Harbour headers are: wapi_*.ch Question is, what should '*' be. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi Pritpal, --- wapi_commctrl.c (now) #include #include #include "hbapi.h" #include "hbwapi.h" --- Please don't explicitly #include , it's not necessary, as it's automatically pulled in by hbapi.h by #defining HB_OS_WIN_USED. This is the clean way (notice that commctrl.h is moved after Harbour headers, and windows.h got deleted): --- wapi_commctrl.c (corrected) #include "hbapi.h" #include "hbwapi.h" #include --- --- hbwapi.h (now) #define wapi_ret_HANDLE( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retnint( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) --- This isn't ideal, we should use hb_retptr() otherwise the caller can easily mess up the values and cause various security holes, GPFs and other random behaviour. I'd suggest to change this right from the start, before introducing numeric dependent code in hbwin itself, too. With these pointers, .prg level code should only do equality check, call hb_IsPointer() and Empty() on these values. Everything else is to be avoided. --- hbwapi.h (corrected) #define wapi_ret_HANDLE( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) --- Even more ideally we should switch to hb_retptrGC() to avoid resource leaks due to .prg level programming errors, but this can be done later. Brgds, Viktor On Sat, Feb 14, 2009 at 10:46 PM, wrote: > Revision: 10273 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10273&view=rev > Author: vouchcac > Date: 2009-02-14 21:46:19 + (Sat, 14 Feb 2009) > > Log Message: > --- > 2009-02-14 13:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > + harbour/contrib/hbwin/wapi_commctrl.c >+ Added WAPI_Image*() functions. > > * harbour/contrib/hbwin/hbwapi.h >+ Added more _par and _ret defines. > >; The idea is to encapsulate Harbour API for WINAPI > parameters and return values. Now wapi_commctrl.c > looks very clean and easy to understand code. > Also I have contained all those functions which are > either not required on normal programming level > OR I could not convert, with #if 0 / #endif blocks. > But the header definitions are pulled from MSDN and > have been kept alongwith. This ensures that whenever > someone will try to implement them, all info will be > handy. > >; Please approve the above implementation so that I > include these files in the build batches. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbwin/hbwapi.h > > Added Paths: > --- >trunk/harbour/contrib/hbwin/wapi_commctrl.c > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi Pritpal, Ops, sorry I forgot one important issue, could you please use ANSI C comments only? This rule wasn't lifted from hbwin, so we should stick to it to be ANSI C compliant. --- wapi_commctrl.c (now) //--// // BEGIN - ImageList_* - API //--// --- wapi_commctrl.c (correct) /*-- BEGIN - ImageList_* - API -- */ Brgds, Viktor On Sat, Feb 14, 2009 at 10:46 PM, wrote: > Revision: 10273 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10273&view=rev > Author: vouchcac > Date: 2009-02-14 21:46:19 + (Sat, 14 Feb 2009) > > Log Message: > --- > 2009-02-14 13:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > + harbour/contrib/hbwin/wapi_commctrl.c >+ Added WAPI_Image*() functions. > > * harbour/contrib/hbwin/hbwapi.h >+ Added more _par and _ret defines. > >; The idea is to encapsulate Harbour API for WINAPI > parameters and return values. Now wapi_commctrl.c > looks very clean and easy to understand code. > Also I have contained all those functions which are > either not required on normal programming level > OR I could not convert, with #if 0 / #endif blocks. > But the header definitions are pulled from MSDN and > have been kept alongwith. This ensures that whenever > someone will try to implement them, all info will be > handy. > >; Please approve the above implementation so that I > include these files in the build batches. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbwin/hbwapi.h > > Added Paths: > --- >trunk/harbour/contrib/hbwin/wapi_commctrl.c > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Viktor < --- wapi_commctrl.c (now) #include #include #include "hbapi.h" #include "hbwapi.h" --- Please don't explicitly #include , it's not necessary, as it's automatically pulled in by hbapi.h by #defining HB_OS_WIN_USED. This is the clean way (notice that commctrl.h is moved after Harbour headers, and windows.h got deleted): --- wapi_commctrl.c (corrected) #include "hbapi.h" #include "hbwapi.h" #include --- > OK. I was not sure about the sequence, so.. --- hbwapi.h (now) #define wapi_ret_HANDLE( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retnint( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) --- This isn't ideal, we should use hb_retptr() otherwise the caller can easily mess up the values and cause various security holes, GPFs and other random behaviour. I'd suggest to change this right from the start, before introducing numeric dependent code in hbwin itself, too. With these pointers, .prg level code should only do equality check, call hb_IsPointer() and Empty() on these values. Everything else is to be avoided. --- hbwapi.h (corrected) #define wapi_ret_HANDLE( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) --- I agree your implementation is valid, but then it holds good for new PRG code only. If we return pointers and in the next call we sent it back to another function, then it has to be retried as wapi_par_POINTER()? Or I am missing something. If this is the case then I am afraid the wrappers I will be writing will be usable in my applications or not. Most of the functions designed in few years are adapted to numeric values only. It also implies that I have to rewrite my souces again, which is not at my priority list at present. Yes off course for new developments it is the ideal situation. So, if I cannot test my existing code, there is no motivation for me to write wrappers. My existing libraries are serving my purpose for sure. Or if you have some other thoughts ? <<< Even more ideally we should switch to hb_retptrGC() to avoid resource leaks due to .prg level programming errors, but this can be done later. >>> Yes for sure, but it is not exactly the same with WINAPI. For example: Method One() ::hBitmap := WAPI_LoadImage(...) Method Destroy() WAPI_DeleteObject( ::hBitmap )// How this will be handelled in GC? Still thinking how can be lived with both worlds. One thought comes to me: wapi_commctrl.c #if defined( HB_HANDLES_AS_POINTERS ) #define wapi_ret_HANDLE( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) #else #define wapi_ret_HANDLE( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) #define wapi_ret_HRESULT( hr ) ( hb_retnint( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) #endif Until one can switch to finer mode. Opinions... Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10273--trunk-harbour-tp22017357p22017970.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi Pritpal, > > > I agree your implementation is valid, but then it > holds good for new PRG code only. > > If we return pointers and in the next call we sent it back to > another function, then it has to be retried as wapi_par_POINTER()? > Or I am missing something. Yes, it should be retrieved using hb_parptr(). But, here on retrieval, we can be flexible, and also accept numeric: ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) > If this is the case then I am afraid the wrappers I will be writing > will be usable in my applications or not. Most of the functions > designed in few years are adapted to numeric values only. > It also implies that I have to rewrite my souces again, which > is not at my priority list at present. Since we're developing a Harbour component here, and a new one, we should aim for best quality, not compatibility. I'd suggest to gradually clean your code and switch to hbwin then. > Yes off course for new developments it is the ideal situation. > So, if I cannot test my existing code, there is no motivation for > me to write wrappers. My existing libraries are serving my purpose > for sure. > Or if you have some other thoughts ? We already have several non-generic/duplicate/parallel implementations of winapis inside Harbour, so now we should aim for a good one, not yet another compromise. That was the goal we've discussed and agreed on last week. If we go the same route with the same mistakes as the previous implementations, I see no point to deal with this topic in such depth. Sorry to say that, but in Harbour we shouldn't use limitations because of your own local codebase. If we go this route we just unnecessarily limit ourselves, and we lose the freedom of doing it the way we've decided. To keep compatibility with your own code, we need to give up a lot of what we've discussed last week. Again, the point is to have one good quality Windows API wrapper collection which satisfies most users, and which can be used from .prg, safely and easily. If this cannot be done, we don't have to use any new naming, just carefully merge the currently spread WIN_ functions (from gtwvg, hbole, uhttpd) under hbwin library, that's all. Yes for sure, but it is not exactly the same with WINAPI. > For example: > Method One() > ::hBitmap := WAPI_LoadImage(...) > > Method Destroy() > WAPI_DeleteObject( ::hBitmap )// How this will be handelled in GC? When creating a GC collected object, you also specify a destructor function which gets called when the object should be freed, so in this destructor function you call DeleteObject(), and you're done. In fact, you don't even need to use WAPI_DeleteObject() on the .prg level, as it's handled automatically. Please examine the code I've sent to you to the list a few weeks ago. (FFIND API, and maybe another one). I've also pointed you to hbcurl, or the new hbssl, where such method is used for several objects. Once you get the scheme, it's not at all complicated. > One thought comes to me: > > wapi_commctrl.c > > #if defined( HB_HANDLES_AS_POINTERS ) >#define wapi_ret_HANDLE( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) > #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) > #define wapi_ret_COLORREF( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) > #else >#define wapi_ret_HANDLE( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) > #define wapi_ret_HRESULT( hr ) ( hb_retnint( ( HB_PTRDIFF ) hr ) ) > #define wapi_ret_COLORREF( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) > #endif > > Until one can switch to finer mode. Maybe if the default is hb_retptr() for Harbour. But even then the problem is that it will create confusion and incompatibility for .prg code. Should we then have hbwinptr.lib and hbwinnum.lib, too? :) It just makes things weird. It's generally not a good idea to do these kind hacks in the lib to please one specific application. Instead, if I were you, I'd create a new #define to cover type check (later easily switchable to hb_IsPointer()), plus start to switch to EMPTY() instead of '== 0'. Switching to EMPTY() is safe even if you use numerics. Also see this article, I've just read it today, and it's on topic: http://blogs.msdn.com/oldnewthing/archive/2009/02/13/9416485.aspx Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi Viktor I agree with whole concept. Let us do it right, right now. Only pointers, no numeric handles at all. Basically, if we have to use existing code too, we will be changing the function calls and there stays the whole effort. So, it should be like: #define wapi_par_HWND( n ) ( ( HWND ) ( HB_PTRDIFF ) hb_parptr( n ) ) just to avoid the cost of - ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) OR the flexible way is better in the long run? BTW, this artical is really thought provoking. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10273--trunk-harbour-tp22017357p22018462.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi Viktor I did changed hbwapi.h as #define wapi_par_WNDPROC( n )( ( WNDPROC) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_WPARAM( n ) ( ( WPARAM ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_LPARAM( n ) ( ( LPARAM ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HWND( n ) ( ( HWND ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HDC( n )( ( HDC) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HANDLE( n ) ( ( HANDLE ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HGDIOBJ( n )( ( HGDIOBJ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HBITMAP( n )( ( HBITMAP) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HICON( n ) ( ( HICON ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HIMAGELIST( n ) ( ( HIMAGELIST ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HFONT( n ) ( ( HFONT ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_HINSTANCE( n ) ( ( HINSTANCE ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_COLORREF( n ) ( ( COLORREF ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) ) #define wapi_par_STRUCT( n ) ( hb_parc( n ) ) #define wapi_par_INT( n )( hb_parni( n ) ) #define wapi_par_UINT( n ) ( ( UINT ) hb_parni( n ) ) #define wapi_ret_NI( i ) ( hb_retni( i ) ) #define wapi_ret_L( b ) ( hb_retl( b ) ) #define wapi_ret_HANDLE( h ) ( hb_retptr( ( HB_PTRDIFF ) h ) ) #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) #define wapi_ret_COLORREF( cr ) ( hb_retptr( ( HB_PTRDIFF ) cr ) ) And compiled wapi_commctrl.c and I get tons of errors like : Error E2349 wapi_commctrl.c 195: Nonportable pointer conversion in function HB_FUN_WAPI_IMAGELIST_DRAWEX and Error E2349 wapi_commctrl.c 148: Nonportable pointer conversion in function HB_FUN_WAPI_IMAGELIST_DRAGLEAVE I am sure I am missing something, but what ? Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10273--trunk-harbour-tp22017357p22018577.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10273] trunk/harbour
Hi And this sets everything right, please review: #define wapi_par_WNDPROC( n )( ( WNDPROC) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_WPARAM( n ) ( ( WPARAM ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_LPARAM( n ) ( ( LPARAM ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HWND( n ) ( ( HWND ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HDC( n )( ( HDC) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HANDLE( n ) ( ( HANDLE ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HGDIOBJ( n )( ( HGDIOBJ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HBITMAP( n )( ( HBITMAP) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HICON( n ) ( ( HICON ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HIMAGELIST( n ) ( ( HIMAGELIST ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HFONT( n ) ( ( HFONT ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_HINSTANCE( n ) ( ( HINSTANCE ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_COLORREF( n ) ( ( COLORREF ) ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : ( HB_PTRDIFF ) hb_parptr( n ) ) ) #define wapi_par_STRUCT( n ) ( hb_parc( n ) ) #define wapi_par_INT( n )( hb_parni( n ) ) #define wapi_par_UINT( n ) ( ( UINT ) hb_parni( n ) ) #define wapi_ret_NI( i ) ( hb_retni( i ) ) #define wapi_ret_L( b ) ( hb_retl( b ) ) #define wapi_ret_HANDLE( h ) ( hb_retptr( h ) ) #define wapi_ret_HRESULT( hr ) ( hb_retptr( hr ) ) #define wapi_ret_COLORREF( cr ) ( hb_retnint( ( HB_PTRDIFF ) cr ) ) COLORREF is always accepted as 'long' and not as a pointer. Regards Pritpal Bedi PS Now some real usage of ImageList_*() functions. -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10273--trunk-harbour-tp22017357p22018701.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10274] trunk/harbour
Revision: 10274 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10274&view=rev Author: vszakats Date: 2009-02-15 01:21:12 + (Sun, 15 Feb 2009) Log Message: --- 2009-02-15 02:22 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg + Added support for parameters passed in files: 'hbmk @myprogram.hbm'. Multiple scripts can be passed, and they can be combined with normal command line options. This makes it possible to supply quasi make files for programs. + Added support for hbmake parameter (.hbp) files. hbmk will scan current dir for .hbp files and process them. .hbp files can specify user libs, .prg options, can control MT, GUI, NULRDD, SHARED, DEBUG, STRIP and can select GT. This makes it ideal to offer automatic setup for lib dependent programs, f.e. an .hbp can be places in contrib test dirs to allow for a configuration free make process without the need of any helper batch/script files. 3rd party makers can also supply .hbp file for the same effect, f.e. xhgtk, hwgui support may be added this way, without hard-wiring knowledge into hbmk itself. -nohbp disables processing of these files. + Added support for HB_GT envvar. + -o support for win/msvc. ! Fix to GT handling and -shared to for msvc and bcc32. ! Fixed some envvar names. * utils/hbi18n/hbi18n.prg * Minor typo. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbi18n/hbi18n.prg trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10275] trunk/harbour
Revision: 10275 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10275&view=rev Author: vszakats Date: 2009-02-15 01:29:22 + (Sun, 15 Feb 2009) Log Message: --- 2009-02-15 02:30 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg ! Fix to previous commit. * Help screen made more compact. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10276] trunk/harbour
Revision: 10276 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10276&view=rev Author: vszakats Date: 2009-02-15 07:58:03 + (Sun, 15 Feb 2009) Log Message: --- 2009-02-15 08:56 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk/hbmk.prg + Added -bldflags option which tells hbmk to also apply user build flags (HB_USER_*FLAGS) used when building Harbour. * Minor internal cleanups. ! Typo in help screen. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk/hbmk.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
