Re: [Harbour] Re: SF.net SVN: harbour-project:[14611] trunk/harbour
Hi Pritpal, 1. Flagship lexer is not implemented in QScintilla which I did. 2. May be it can go, but a lot of warnings while compiling QScintilla as per Harbour make system. 3. I could only build static lib, .a, and do not know how to a shared one, .dll. 4. One serious issue which I could not resolve, commenting out a line delete [] words; solved the problem, otherwise GPF. I know it may lead to leaked memory but unless someone with more knowledge look into it, I could not fix. words is defined as - char * words. 5. It is just the begining, I may need some more tweaking to achieve some more goals, so may be needing to tweak Scintilla sources itself. 6. Author, Phil Thomson, did not reply when I offered Flagship lexer code to him plus few fixes to get rid of the warnings. His only reply was, I don't understand this. By including QScintilla your application must becompatible with the GPL. This means that you must make all the source codeavailable to your users, and allow them to rebuild the application. So whycan't you build it yourself as well? Maybe in a public forum can expect a change, but when there are comercial interests... I don't know. :( http://groups.google.com/group/scintilla-interest/browse_thread/thread/557fb713f11f09be Best regards, -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] QScintilla - Harbour Port
http://hbide.vouch.info/downloads/QScintilla.zip It's recommendable update the component with their respective original sources. ;) http://scintilla.cvs.sourceforge.net/viewvc/scintilla/scintilla/include/SciLexer.h?revision=1.176view=markup http://scintilla.cvs.sourceforge.net/viewvc/scintilla/scintilla/src/LexFlagship.cxx?revision=1.5view=markup Unfortunately if this is not said, users take months, years, to have the improvements. -- Xavi El 16/05/2010 17:17, Pritpal Bedi escribió: Hello Everybody Here is the port of QScintill to Harbour. The port is based on hbMK2 and generates static libraries. I will be interested in .dll generation due its license restrictons. I tried to adopt it to Harbour's make system but failed because of header locations. Just unzip the linked file in /contrib/hbqt and files will go into hbqt/QScintilla. It contains .hbp projects. Note that few moc_*.cpp's are generated manually for only some files I was experimenting with. My first impressions are that this can be embedded into If possible I would like it to be a part of hbqt. http://hbide.vouch.info/downloads/QScintilla.zip - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14273] trunk/harbour
El 06/04/2010 8:26, Viktor Szakáts escribió: Sorry to ask, but what is this patch meant to do? It looks totally wrong to modify SETCANCEL flag internally from GT code, pls revert ASAP! Sorry... ??? This does the same that GTWVT so the same code has the same behavior in both. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14273] trunk/harbour
El 06/04/2010 9:33, Viktor Szakáts escribió:
False. In GTWVT it will only do it if callback says to do so,
and it instantly exists the application (that's why it modifies
this flag internally - I guess).
GTWVT do this without callback, you need to program a express callback to not
do so return 1 i.e.
if not exist NotifierBlock callback hb_gt_wvt_FireEvent return 0 and do so.
static int hb_gt_wvt_FireEvent( PHB_GTWVT pWVT, int nEvent )
{
int nResult = 0; /* Unhandled */
if( pWVT-pGT-pNotifierBlock )
{
...
}
return nResult;
}
...
case WM_CLOSE: /* Clicked 'X' on system menu */
if( hb_gt_wvt_FireEvent( pWVT, HB_GTE_CLOSE ) == 0 )
{
PHB_ITEM pItem = hb_itemPutL( NULL, HB_TRUE );
hb_setSetItem( HB_SET_CANCEL, pItem );...
...
In GTWIN, it just sets the SETCANCEL flag and lets the
app continue to run.
This is what I tried to say and do many times.
Could you explain what must be the behavior for both?
I've no objection to change.
Best regars,
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14273] trunk/harbour
Hi Viktor,
Remember my Fixing about this .-
2010-03-01 14:45 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
...
* src/rtl/gtwvt/gtwvt.c
! Reverted close/SETCANCEL/HB_GTI_CLOSABLE behavior to
match the old one and that of other GTs.
Also see:
2008-06-25 11:49 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
Please use HB_GTI_CLOSABLE and HB_GTI_NOTIFIERBLOCK
to control GUI window close behavior.
...
2010-03-01 04:05 UTC+0100 Xavi (jarabal/at/gmail.com)
* harbour/src/rtl/gtwvt/gtwvt.c
! Fixing WM_CLOSE event (Clicked 'X' on system menu)
to avoid irregular shutdown with SETCANCEL( .F. )
REQUEST HB_GT_WVT_DEFAULT
ANNOUNCE HB_GTSYS
PROCEDURE Main()
SetCancel(.F.)
? Click [X] Not close windows
while( LastKey() != 27 )
Inkey( 1 )
enddo
RETURN
Best regars,
Xavi
El 06/04/2010 11:29, Viktor Szakáts escribió:
On Tue, Apr 6, 2010 at 10:40 AM, Xavijara...@gmail.com wrote:
El 06/04/2010 9:33, Viktor Szakáts escribió:
False. In GTWVT it will only do it if callback says to do so,
and it instantly exists the application (that's why it modifies
this flag internally - I guess).
GTWVT do this without callback, you need to program a express callback to
not do so return 1 i.e.
if not exist NotifierBlock callback hb_gt_wvt_FireEvent return 0 and do
so.
static int hb_gt_wvt_FireEvent( PHB_GTWVT pWVT, int nEvent )
{
int nResult = 0; /* Unhandled */
if( pWVT-pGT-pNotifierBlock )
{
...
}
return nResult;
}
...
case WM_CLOSE: /* Clicked 'X' on system menu */
if( hb_gt_wvt_FireEvent( pWVT, HB_GTE_CLOSE ) == 0 )
{
PHB_ITEM pItem = hb_itemPutL( NULL, HB_TRUE );
hb_setSetItem( HB_SET_CANCEL, pItem );...
...
In GTWIN, it just sets the SETCANCEL flag and lets the
app continue to run.
This is wrong solution. SETCANCEL is not something
the app sets. SETCANCEL is a way to let app developers
_control_ the behavior of Ctrl+C. Nothing more. What you
committed just creates a hidden extension plus incompatible
to Clipper behavior (since in Clipper SETCANCEL flag was
never modified by window closure).
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
Hi Viktor, Ok. Best regards, Xavi El 05/04/2010 0:12, Viktor Szakáts escribió: Hi, Me neither, I guess that Tortoise always makes the patch with the latest version... I correct it manually, no problem. Maybe it's better to do all the changes in the repository or don't change any in a file under discussion. I don't know. The best is to send .diffs against latest source tree: svn update svn diff patch.dif (and .zip it or paste it if it's only for review and short) conditional code for layered mode (why?) and you still try to force your setcancel hack. It also employs trick to track focus, and I'm not sure I like it. Conditional compiler time code with layered mode is to link the two issues. Use layered model by the buffer like a opaque window when is not opaque until remove the attribute. It's also faster without WS_EX_LAYERED and simple not have to check if exist WS_EX_LAYERED and not exit WS_EX_COMPOSITED. I want to record in the code, in the form of a conditional compiler time, the option. Please don't add new knobs, I'm working hard to remove them, and for the sake of maintainability and to avoid unnecessary build-types, such built-time knobs are not welcome in the code. It's not a whim. I've help and moved many codes Clipper to Harbour. I don't know what answer when asked to why left the execution of a code-protected by SetCancel(.F.)/SetCancel(.T.) when clicked [X] on title windows bar. I say that use SET CLOSABLE OFF new in Harbour but they say it's too easy to forget and the codes are already written. Then I think why not say so in public devel-list but... I also think it is better to keep quiet because it's my job. :( UpdateCaret try create caret when is in the background, I like to keep clean Windows LastError whenever possible and easy. In problems like this can be important. Trick to track focus allow this, can also be interesting to know this condition. I find it rather offensive/disturbing that you keep posting this piece of code for the 5th time, while it's clearly against concept and project goals and you can't address any of the concerns I raised here several times (and which I won't repeat this time). Moreover it doesn't bring anything new to Harbour, just limits current features by tying to different settings into one. In my view the SVN should contain stuff which is useful for most users, and stuff which we've agreed upon, and not support for special personal needs or undiscussed (rogue) changes at will. If you don't agree with this and/or with major directions of development, it's best to keep a local patch on your system (and optionally publish these patches and binaries for interested users, if there are any). This is one of the advantages of open source. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
Hi Viktor, I don't understand this patch, it's against an older version of the files (missing my last minor update), you added Me neither, I guess that Tortoise always makes the patch with the latest version... I correct it manually, no problem. Maybe it's better to do all the changes in the repository or don't change any in a file under discussion. I don't know. conditional code for layered mode (why?) and you still try to force your setcancel hack. It also employs trick to track focus, and I'm not sure I like it. Conditional compiler time code with layered mode is to link the two issues. Use layered model by the buffer like a opaque window when is not opaque until remove the attribute. It's also faster without WS_EX_LAYERED and simple not have to check if exist WS_EX_LAYERED and not exit WS_EX_COMPOSITED. I want to record in the code, in the form of a conditional compiler time, the option. It's not a whim. I've help and moved many codes Clipper to Harbour. I don't know what answer when asked to why left the execution of a code-protected by SetCancel(.F.)/SetCancel(.T.) when clicked [X] on title windows bar. I say that use SET CLOSABLE OFF new in Harbour but they say it's too easy to forget and the codes are already written. Then I think why not say so in public devel-list but... I also think it is better to keep quiet because it's my job. :( UpdateCaret try create caret when is in the background, I like to keep clean Windows LastError whenever possible and easy. In problems like this can be important. Trick to track focus allow this, can also be interesting to know this condition. IMO the issue to be resolved doesn't justify any sort of irregular tricks or any chance for performance drop down. I agree and I think, of course, don't do this. Pls consult with Przemek about it. Ok. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
El 01/04/2010 19:26, Viktor Szakáts escribió: BTW there were a lot of screen painting irregularities without WS_EX_LAYERED, when the window was behind another window and foremost window was moved. It also fixes painting issue when app is doing a loop, or otherwise unresponsive. Thanks but this is under control. Remember that GTWVT is a pure Windows GUI and it need to process messages to refresh the screen. It does this with the outputs to screen and inputs from keyboard. In typical code like loops with pure RDDs you can force this with SetPos .- nCursor := SetCursor( 0 ) WHILE !EOF() SetPos( 0, 0 ) ... SKIP() ENDDO SetCursor( nCursor ) Of course it supports many optimizations. if( ++n % 1 == 0 ); SetPos( 0, 0 ); endif Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
... In typical code like loops with pure RDDs you can force this with SetPos .- nCursor := SetCursor( 0 ) WHILE !EOF() SetPos( 0, 0 ) ... SKIP() ENDDO SetCursor( nCursor ) Of course it supports many optimizations. if( ++n % 1 == 0 ); SetPos( 0, 0 ); endif Sorry, ... and I think that is not even necessary because the VM does calling hb_inkeyPoll :) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
Hi Przemek, [...] Anyhow I always prefer to detect real reason of problem first to check if such modification is really necessary and the problem is not side effect of some other code or bugs. Otherwise each of us will add some new peaces of code which only mask real bugs making the whole code hard to understand and extend. I agree with this. If you want then I can add code which will make caret SetCaretPos()/ ShowCaret() optimization and maybe it will help you to find when the cursor is wrongly refreshed. Please do it. I can look more in depth. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Ghost cursor with GTWVT
Hi Przemek, ShowCaret() optimization and maybe it will help you to find when the cursor is wrongly refreshed. I think I've found the root of the issue. Please don't nothing about it. Let me do some checking, ...tonight. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Ghost cursor with GTWVT
Hi all,
Sometimes GTWVT leaves the previous mark of cursor. Attached picture to
illustrate the issue.
This happens because the pre-cursor position not is marked with InvalidateRect (RedrawDiff not find differences) getting knocked
out of WM_PAINT.
In GTWVG not happen because overwrite PutChar and for each character insert call TouchCell and force RedrawDiff to find
differences although they are the same characters and atributes.
IMHO is more effective in Windows marking only the previous cursor position.
I would like to commit the following patch to the repository.
Index: gtwvt.c
===
--- gtwvt.c (revision 14260)
+++ gtwvt.c (working copy)
@@ -1683,15 +1683,19 @@
case WM_QUERYENDSESSION: /* Closing down computer */
hb_vmRequestQuit();
- return 0;
+ break; /* DefWindowProc return TRUE [jarabal] */
case WM_CLOSE: /* Clicked 'X' on system menu */
- if( hb_gt_wvt_FireEvent( pWVT, HB_GTE_CLOSE ) == 0 )
{
+#if 0 /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
+if( hb_setGetCancel() )
+ hb_vmRequestCancel();
+#else
PHB_ITEM pItem = hb_itemPutL( NULL, HB_TRUE );
hb_setSetItem( HB_SET_CANCEL, pItem );
hb_itemRelease( pItem );
hb_vmRequestCancel();
+#endif
}
return 0;
@@ -2939,7 +2943,20 @@
}
/* ** */
+/* Avoid the possible remnant mark of cursor in some cases [jarabal] */
+static void hb_gt_wvt_SetPos( PHB_GT pGT, int iRow, int iCol )
+{
+ PHB_GTWVT pWVT = HB_GTWVT_GET( pGT );
+ if( pWVT pWVT-CaretExist !pWVT-CaretHidden )
+ HB_GTSELF_REDRAW( pGT, pGT-iRow, pGT-iCol, 1 );
+
+ pGT-iRow = iRow;
+ pGT-iCol = iCol;
+}
+
+/* ** */
+
static HB_BOOL hb_gt_wvt_SetDispCP( PHB_GT pGT, const char * pszTermCDP,
const char * pszHostCDP, HB_BOOL fBox )
{
HB_GTSUPER_SETDISPCP( pGT, pszTermCDP, pszHostCDP, fBox );
@@ -3046,6 +3063,7 @@
pFuncTable-SetMode = hb_gt_wvt_SetMode;
pFuncTable-Redraw = hb_gt_wvt_Redraw;
pFuncTable-Refresh = hb_gt_wvt_Refresh;
+ pFuncTable-SetPos = hb_gt_wvt_SetPos;
pFuncTable-Version = hb_gt_wvt_Version;
pFuncTable-Tone = hb_gt_wvt_Tone;
pFuncTable-Info = hb_gt_wvt_Info;
--
Xavi
attachment: MemoEdit.jpg___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] field-(name) in a macro
Harbour has the same behavior as Clipper .-
proc main()
PUBLIC VAR := 'Hello'
? M-(VAR) // Ok
? xxx( VAR ) // Ok
? Eval( ('{|| M-'+VAR+'}') ) // Ok
? Eval( ('{|| M-(VAR) }') ) // Error BASE/1449 Syntax error:
return
func xxx( name )
// b := ( {|| field- + name + } )
local b := ( {|| M- + name + } )
return eval( b )
PS At least with this. :)
HTH
--
Xavi
El 20/03/2010 23:06, Alexandr Okhotnikov escribió:
Hi,
How can I compile (and run) this code in a macro:
field-(name)
example:
func xxx( name )
local b :=( {|| field-(' + name + ') } )
return eval( b )
Error BASE/1449 Syntax error:
PS in *.hrb the exact same error
PPS Alaska XBase++: compiles without errors
(I convert the code from XBase++)
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Can harbour print to STDOUT?
Can harbour print to the STDOUT? ... hbmk2 program.prg -gtstd program.exe out.txt -- Xavi El 09/03/2010 2:59, smu johnson escribió: Hi, I've googled for something relevant in the dev archives, but haven't found anything that really is related to my question. Can harbour print to the STDOUT? My cute program below does not: FUNC MAIN() PARAM cOne, cTwo ? cOne ? cTwo RETURN Trying to capture the output by piping it in cmd.exe in Windows just won't do it, as it probably has it's own console writing calls that are beyond my brain capacity. Thank you -- smu johnson smujohn...@gmail.com mailto:smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Thanks Saulius,
At least SetConsoleMenuClose grayed also the option Close in caption menu not
only the button in title bar. :)
I still don't understand why we have to introduce HB_BREAK_FLAG in Inkey Poll
in response to CTRL_CLOSE_EVENT.
I think if we do this .-
---
Index: gtwin.c
===
--- gtwin.c (revision 14068)
+++ gtwin.c (working copy)
@@ -569,9 +569,9 @@
bHandled = FALSE;
break;
- case CTRL_CLOSE_EVENT:
case CTRL_BREAK_EVENT:
s_bBreak = HB_TRUE;
+ case CTRL_CLOSE_EVENT:
bHandled = TRUE;
break;
---
Everyone happy and does the same that Clipper program with .-
PROCEDURE Main()
? Click [X] Not close windows
Wait
RETURN
Best regards,
--
Xavi
El 05/03/2010 10:19, Saulius Zrelskis escribió:
[for those interested]
Sample below really controls console close button on Windows XP and
later systems. Please test it and enjoy:)
---
#include 'inkey.ch'
proc main()
local nKey
while (nKey := Inkey(0)) # K_ESC
Qout(Str(nKey) +' ' +Chr(nKey) +'')
if nKey == Asc(0) .or. nKey == Asc(1)
SetConsoleMenuClose(nKey == Asc(1))
Qqout(if(SetConsoleMenuClose(), ' enabled', ' disabled'))
endif
end
return
#PRAGMA BEGINDUMP
#include windows.h
#include hbapi.h
BOOL WINAPI
SetConsoleMenuClose( IN BOOL fEnable );
// SetConsoleMenuClose( lEnable ) - lPreviousState
HB_FUNC( SETCONSOLEMENUCLOSE )
{
HMENU hSysMenu = GetSystemMenu( GetConsoleWindow(), FALSE );
if( hSysMenu )
{
BOOL fCurrent = ( GetMenuState( hSysMenu, SC_CLOSE, MF_BYCOMMAND
) MF_GRAYED ) == FALSE;
if( hb_pcount() )
{
BOOL fEnable = hb_parl( 1 );
if( fCurrent != fEnable )
{
/*
SetConsoleMenuClose() API really controls Close Menu
status, but forgets
to gray close button on titlebar. EnableMenuItem() API
does this trick.
Without SetConsoleMenuClose() clicking on titlebar icon
close button becomes enabled.
*/
SetConsoleMenuClose( fEnable );
EnableMenuItem( hSysMenu, SC_CLOSE, MF_BYCOMMAND | (
fEnable ? MF_ENABLED : MF_GRAYED ) );
}
}
hb_retl( fCurrent );
}
else
hb_retl( FALSE );
}
#PRAGMA ENDDUMP
---
Best regards,
Saulius
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Hi, Did you test this code? Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM differs. IMHO this difference can be assumed because the code must be fixed in MT mode. [ #if ! defined( HB_MT_VM ) 0 if( hb_setGetCancel() ) s_bBreak = HB_TRUE; #endif ] But I do a new question. How can it be fixed something that does not exist? [ And is not valid the quick answer does not exist, no problem because by this logic Harbour would be perfect if not exist. :) ] Best regards, -- Xavi El 04/03/2010 8:31, Viktor Szakáts escribió: Hi Xavi, Yes, you're right. I have another patch to fix this, IMHO a issue, but I don't have right to commit it, there are two differents points of view and few opinions. Please note that GTWIN behavior is the same as a Clipper program under NTVDM. --- .patch Index: gtwin.c === --- gtwin.c (revision 14052) +++ gtwin.c (working copy) @@ -563,7 +563,9 @@ case CTRL_CLOSE_EVENT: case CTRL_BREAK_EVENT: - s_bBreak = HB_TRUE; + /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */ + if( hb_setGetCancel() ) +s_bBreak = HB_TRUE; bHandled = TRUE; break; Did you test this code? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Did you test this code? Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM differs. I was referring to your patch. Did you try it with a test application with both SETCANCEL(.T.) and SETCANCEL(.F.) ? IMHO this difference can be assumed because the code must be fixed in MT mode. [ #if ! defined( HB_MT_VM ) 0 if( hb_setGetCancel() ) s_bBreak = HB_TRUE; #endif ] I tested in ST mode, and s_bBreak has no effect on the application termination, meaning that it will be _always_ closed. (regardless of SETCANCEL() or whatever else control we use here) ... !!! ??? Sorry... What's happening? :) Please tell me more. Have these tested in a real Windows machine? What version of Windows OS? What version of kernel32.dll? Does the same thing the Clipper's program on your machine? Obviously I have the expected result in XP SP3. kernel32.dll version 5.1.2600.5512 DLL de cliente API BASE de Windows NT http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx The system also displays this dialog box if the process does not respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT). -- Xavi El 04/03/2010 14:52, Viktor Szakáts escribió: Did you test this code? Yes, if you're referring to that SetCancel( .T. ) Clipper's program under NTVDM differs. I was referring to your patch. Did you try it with a test application with both SETCANCEL(.T.) and SETCANCEL(.F.) ? IMHO this difference can be assumed because the code must be fixed in MT mode. [ #if ! defined( HB_MT_VM ) 0 if( hb_setGetCancel() ) s_bBreak = HB_TRUE; #endif ] I tested in ST mode, and s_bBreak has no effect on the application termination, meaning that it will be _always_ closed. (regardless of SETCANCEL() or whatever else control we use here) But I do a new question. How can it be fixed something that does not exist? I don't know what you mean, sorry. Nothing needs to be fixed, since nothing is currently wrong or broken. AFAICS what you want is to attach GT specific window-close behavior to SETCANCEL(). Current behavior is not a bug, but by design. I can't see why you want to limit current possibilities and make it impossible to have a working Ctrl+C key plus a regular closable window. Not to mention that you can't attach window-close behavior is several GTs, GTWIN is just one of those, we also have GTOS2, GTSTD, GTPCA, GTDOS, GTTRM, GTCRS, GTSLN. Please notice that a window per se is not in reach with all/most non-GUI GTs. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Can you describe what is exactly this expected result? http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx Return TRUE. In this case, no other handler functions are called, and the system displays a pop-up dialog box that asks the user whether to terminate the process. The system also displays this dialog box if the process does not respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT). What you don't understand about this part of the official documentation? Need you a picture of the pop-up dialog box which _allows to continue the process_? -- Xavi El 04/03/2010 16:23, Viktor Szakáts escribió: I was referring to your patch. Did you try it with a test application with both SETCANCEL(.T.) and SETCANCEL(.F.) ? IMHO this difference can be assumed because the code must be fixed in MT mode. [ #if ! defined( HB_MT_VM ) 0 if( hb_setGetCancel() ) s_bBreak = HB_TRUE; #endif ] I tested in ST mode, and s_bBreak has no effect on the application termination, meaning that it will be _always_ closed. (regardless of SETCANCEL() or whatever else control we use here) ... !!! ??? Sorry... What's happening? :) Please tell me more. Have these tested in a real Windows machine? It's a VMWare Fusion 3.0.2 VM, but that's irrelevant here. What version of Windows OS? Tested on Win7 x64 using win/mingw (x86) Harbour trunk. What version of kernel32.dll? Does the same thing the Clipper's program on your machine? What do you mean? I'm not aware of any method you can disable NTVDM close for Clipper programs, even less so using SETCANCEL(). But NTVDM is no more on x64 Windows editions. Obviously I have the expected result in XP SP3. Can you describe what is exactly this expected result? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
[ I don't know because I've to answer this. Maybe the last time. :( ] http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function. PROCEDURE Main() SetCancel(.T.) ? Click [X] Not close windows Wait RETURN Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, keyboard buffer. Wait ends and the main process is finished so the new thread to execute the function is killed before it can complete their work. -- Xavi El 04/03/2010 18:47, Viktor Szakáts escribió: http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx Return TRUE. In this case, no other handler functions are called, and the system displays a pop-up dialog box that asks the user whether to terminate the process. The system also displays this dialog box if the process does not respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT). What you don't understand about this part of the official documentation? Read this: Different behavior for Vista and later Master Programmer http://msdn.microsoft.com/en-us/library/user-87514.aspx | Edit | Show History It seems like for Vista and later, the system terminates the process soon after it calls this routine. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Sorry I meant SetCancel(.F.) http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function. PROCEDURE Main() SetCancel(.F.) ? Click [X] Not close windows Wait RETURN Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, keyboard buffer. Wait ends and the main process is finished so the new thread to execute the function is killed before it can complete their work. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Viktor, It also doesn't work on Vista/Win7/2008. Maybe is about CTRL_LOGOFF_EVENT, CTRL_SHUTDOWN_EVENT that is received only by services. But if so is a issue of Vista and Win7/2008, not ours, because the official documentation nothing says about this, AFAIK. And no excuse for not correcting the current Harbour behavior, IMHO. Also in .NET (please see example Visual C++ and Platforms) .- http://msdn.microsoft.com/en-us/library/system.gc.keepalive%28VS.100%29.aspx I tested it on XP x64, there there is a window asking for 'Cancel' and 'End Now', so even here this method cannot prevent the app to be closed by user. In any case it's not a SETCANCEL() thing, Just as DOS Clipper's programs. but maybe rather it could be the standard GTWIN behavior (without any extra setting). For sure it's not a HB_GTI_CLOSABLE setting either. Or, we just leave it as is. IMHO are two different targets, things, HB_GTI_CLOSABLE / SETCANCEL. HB_GTI_CLOSABLE aims to modify the user interface (if possible). SETCANCEL aims to avoid interruption of the code execution by the user (if possible). BTW in te case of GTWVT, I don't think that changing the status of SETCANCEL in response to WM_CLOSE meet the objective of SETCANCEL. -- Xavi El 04/03/2010 20:38, Viktor Szakáts escribió: It also doesn't work on Vista/Win7/2008. Did _you_ read the comments in your quoted (now for the 6th times) article? I tested it on XP x64, there there is a window asking for 'Cancel' and 'End Now', so even here this method cannot prevent the app to be closed by user. In any case it's not a SETCANCEL() thing, but maybe rather it could be the standard GTWIN behavior (without any extra setting). For sure it's not a HB_GTI_CLOSABLE setting either. Or, we just leave it as is. Brgds, Viktor On 2010 Mar 4, at 20:21, Xavi wrote: Sorry I meant SetCancel(.F.) http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function. PROCEDURE Main() SetCancel(.F.) ? Click [X] Not close windows Wait RETURN Now it's happening that you are introduced ch = HB_BREAK_FLAG in Inkey Poll, keyboard buffer. Wait ends and the main process is finished so the new thread to execute the function is killed before it can complete their work. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hb_gt_win_CtrlHandler usage
Hi, I'm trying to write a simple Hello World app that does something like a WAIT command and maybe calls a function if I click the X button for a GTWIN app. Yes, you're right. I have another patch to fix this, IMHO a issue, but I don't have right to commit it, there are two differents points of view and few opinions. Please note that GTWIN behavior is the same as a Clipper program under NTVDM. === * harbour/src/rtl/gtwin/gtwin.c ! Fixing CTRL_BREAK_EVENT, and CTRL_CLOSE_EVENT (Clicked 'X' on system menu) to avoid irregular shutdown with SETCANCEL( .F. ) REQUEST HB_GT_WIN_DEFAULT ANNOUNCE HB_GTSYS PROCEDURE Main() SetCancel(.F.) ? Click [X] Not close windows WAIT RETURN Modified Paths: -- trunk/harbour/src/rtl/gtwin/gtwin.c --- .patch Index: gtwin.c === --- gtwin.c (revision 14052) +++ gtwin.c (working copy) @@ -563,7 +563,9 @@ case CTRL_CLOSE_EVENT: case CTRL_BREAK_EVENT: - s_bBreak = HB_TRUE; + /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */ + if( hb_setGetCancel() ) +s_bBreak = HB_TRUE; bHandled = TRUE; break; --- -- Xavi El 03/03/2010 23:09, smu johnson escribió: Hi, I'm trying to write a simple Hello World app that does something like a WAIT command and maybe calls a function if I click the X button for a GTWIN app. I have no idea if this is even possible, as I have grepped the entire harbour src .zip file contents for some hints. In the few results for CTRL_CLOSE_EVENT I don't really see anything relevant that can like.. set up a call hook function or anything. I'm totally lost. Any hints greatly appreciated. -- smu johnson smujohn...@gmail.com mailto:smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Hi Viktor, [ Sorry for my bad English :'( ] I don't see any need for a make-level solution. All macros can be defined from source. Why is it better to define them on make level? Because if someone tries to compile Harbour with a version of SDK not supported, he don't have compile-time error. If in the example of my previous thread post I protect IP_ADAPTER_ADDRESSES use with .- #if _WIN32_WINNT = 0x0501 ... #endif And the macro _WIN32_WINNT is passed to my code, the code can be compiled with an SDK of 0x0500 and the binary can run on any version, just don't have this functionality in earlier versions. Please note that the same thing happens with the basic functionality of ws2_32.dll if we don't implement an alternative. So the use of dynamic calls is only justified for functions with alternative because if there is no alternative simply does not have this functionality in earlier versions, IMHO. Best regards, -- Xavi El 28/02/2010 19:09, Viktor Szakáts escribió: NTDDI_VERSION = maximum OS version supported by SDK/Windows-headers _WIN32_WINNT = OS version we want to target Okay, but if you remember my thread starting post .- IMHO the best solution is to define the version of Windows that supports the C compiler before compilation. For example, if your C compiler supports Vista: set HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600 http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx Some structures are defined only in the headers from one version of Windows other may change. IPv6 is supported from Windows Server 2003, Windows XP. Even calling functions dynamically is necessary data with which they work. It can make the binary work with earlier versions but the headers and the code should be protected by .- #if _WIN32_WINNT= 0x0501 ... #endif If not, we can have compile-time errors. Please, what do you think about this, comments? And we *force* _WIN32_WINNT or NTDDI_VERSION in hard code. If someone compiles Harbour with earlier versions of C compiler headers may have compile-time errors. IMHO we need a solution in to make-system and I'm not an expert on this. Sorry but I don't understand this thread anymore. IMO the solution is simple: If you need to use Windows API features which are not supported in all Windows versions: 1) make it using dynamic calls, so binary won't break if feature not available 2) detect OS header version (only this may need compiler specific solutions) 3) force target OS version by defining _WIN32_WINNT before windows.h, if target OS version is known to be supported by headers If only constants are missing you can replace 2) + 3) with simple manual definition of those missing constants. I don't see any need for a make-level solution. All macros can be defined from source. Why is it better to define them on make level? Besides it's quite difficult to discuss this without knowing what do you exactly want to make here. Maybe you could post some code (patch) to see where you're standing at ATM. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14029] trunk/harbour
Hi Viktor,
Please revert this. The behavior was intentionally
designed to be controlled by hb_GTInfo( HB_GTI_CLOSABLE ),
(instead of SETCANCEL()).
Sorry but as you've seen the development list has been off-line many hours.
You've done a reversal before I can read the messages.
Could you explain what is the intention of change because .-
2008-06-25 11:49 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* source/rtl/gtwvt/gtwvt.c
* Slightly changed the way CLOSE button works.
Now the close button, if enabled, will always
force a shutdown. So this setting is made independent
of SetCancel(). I choose this because there might
be cases when we need to use Alt+C in app code, yet
we want to allow closing the window. Previously it was
also easy to create confusing scenarios by using various
combinations of HB_GTI_CLOSABLE + SetCancel(). Another
kind of fix - without the advantage above - would be
to fully sync SetCancel() with HB_GTI_CLOSABLE.
It's very unclear and before the change SetCancel() was respected.
You say: I choose this because there might be cases when we need to use Alt+C in app code, yet we want to allow closing the
window.
Sorry but I don't understand. You change the behavior of GTWVT with SetCancel() respect to GTWIN and GTWVG for something that
you can do in your code with .-
hb_gtInfo( HB_GTI_NOTIFIERBLOCK, {|e| iif( e == HB_GTE_CLOSE, SetCancel(.T.),
nil ), 0} )
Best regards,
--
Xavi
El 01/03/2010 9:32, Viktor Szakáts escribió:
Hi Xavi,
Please revert this. The behavior was intentionally
designed to be controlled by hb_GTInfo( HB_GTI_CLOSABLE ),
(instead of SETCANCEL()).
Brgds,
Viktor
On 2010 Mar 1, at 04:06, jara...@users.sourceforge.net wrote:
Revision: 14029
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14029view=rev
Author: jarabal
Date: 2010-03-01 03:06:26 + (Mon, 01 Mar 2010)
Log Message:
---
2010-03-01 04:05 UTC+0100 Xavi (jarabal/at/gmail.com)
* harbour/src/rtl/gtwvt/gtwvt.c
! Fixing WM_CLOSE event (Clicked 'X' on system menu)
to avoid irregular shutdown with SETCANCEL( .F. )
REQUEST HB_GT_WVT_DEFAULT
ANNOUNCE HB_GTSYS
PROCEDURE Main()
SetCancel(.F.)
? Click [X] Not close windows
while( LastKey() != 27 )
Inkey( 1 )
enddo
RETURN
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rtl/gtwvt/gtwvt.c
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Hi Viktor and all, Well. Some questions. If this is do it an implementation for MinGW. MinGW need to define _WIN32_WINNT before using the headers. http://oldwiki.mingw.org/index.php/header-w32api_h Should I force the code _WIN32_WINNT or use WINVER? Is this true for mingwce? Can I protect the code as standard headers? ... #if _WIN32_WINNT = 0x0501 ... __MINGW32__ and __MINGW64__ they are both compiler 's built-in macros. Is defined in mingwce? Best regards, -- Xavi El 26/02/2010 18:06, Viktor Szakáts escribió: Hi, If there is a way to dynamically find out the version of the structure returned by function in question, so that we can be sure that required fields are present, we may force 0x0600 version in source, just to get the structure definitions from official headers. Plus we also need to add support for older SDK versions, where the newer structure items were not yet available at all (for this there doesn't seem to exist well-known and documented way, so historically we check compiler version, assuming that it's always tied with a given PSDK version (which is theoretically wrong, but works in most installations)). Brgds, Viktor On Fri, Feb 26, 2010 at 5:51 PM, Xavi jara...@gmail.com mailto:jara...@gmail.com wrote: Hi all, IMHO the best solution is to define the version of Windows that supports the C compiler before compilation. For example, if your C compiler supports Vista: set HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600 http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx Some structures are defined only in the headers from one version of Windows other may change. IPv6 is supported from Windows Server 2003, Windows XP. Even calling functions dynamically is necessary data with which they work. It can make the binary work with earlier versions but the headers and the code should be protected by .- #if _WIN32_WINNT = 0x0501 ... #endif If not, we can have compile-time errors. Please, what do you think about this, comments? -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Hi Viktor, I can't see any reason why this have to be compiler specific, please elaborate. In the beginning of hbsocket.c you can see .- ... #elif defined( HB_OS_WIN ) # if defined( __WATCOMC__ ) # if ( NTDDI_VERSION = 0x0600 ) #define HB_HAS_INET_PTON #define HB_HAS_INET_NTOP # endif # define HB_HAS_SOCKADDR_STORAGE /* # define HB_HAS_INET6 */ # elif defined( __MINGW32__ ) # define HB_HAS_SOCKADDR_STORAGE # elif defined( __POCC__ ) !defined( __XCC__ ) # define HB_HAS_SOCKADDR_STORAGE # endif # define HB_IS_INET_NTOA_MT_SAFE ... Please, see the use of NTDDI_VERSION. this platform. I'd guess ipv6 isn't supported by WinCE by I may be wrong. I think that yes .- http://msdn.microsoft.com/en-us/library/aa450087.aspx __MINGW32__ and __MINGW64__ they are both compiler 's built-in macros. Is defined in mingwce? IMO this is not relevant, there is no reason to be compiler specific here. This is general HB_OS_WIN issue. If you want to guard against WinCE, us HB_OS_WIN_CE Harbour macro. Sorry, I meant that if defined __MINGW64__ also is defined __MINGW32__ I don't know in wingwce. [ Viktor Please could you send plain text posts, are much easier to read. ] Best regards, -- Xavi El 28/02/2010 16:01, Viktor Szakáts escribió: Hi, On Sun, Feb 28, 2010 at 3:00 PM, Xavi jara...@gmail.com mailto:jara...@gmail.com wrote: Hi Viktor and all, Well. Some questions. If this is do it an implementation for MinGW. I can't see any reason why this have to be compiler specific, please elaborate. MinGW need to define _WIN32_WINNT before using the headers. http://oldwiki.mingw.org/index.php/header-w32api_h Should I force the code _WIN32_WINNT or use WINVER? Is this true for mingwce? Or rather WinCE in general. You have to check Windows API documentation if the features you need are available or not in this platform. I'd guess ipv6 isn't supported by WinCE by I may be wrong. Can I protect the code as standard headers? ... #if _WIN32_WINNT = 0x0501 IMO, no. (as described in prev answer) __MINGW32__ and __MINGW64__ they are both compiler 's built-in macros. Is defined in mingwce? IMO this is not relevant, there is no reason to be compiler specific here. This is general HB_OS_WIN issue. If you want to guard against WinCE, us HB_OS_WIN_CE Harbour macro. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Hi Viktor, Yes, NTDDI_VERSION is the (best? only?) way to detect platform SDK version. The only problem is that MinGW does not use NTDDI_VERSION, it uses _WIN32_WINNT. At least in my versions of MinGW. :) Best regards, -- Xavi El 28/02/2010 17:18, Viktor Szakáts escribió: In the beginning of hbsocket.c you can see .- ... #elif defined( HB_OS_WIN ) # if defined( __WATCOMC__ ) # if ( NTDDI_VERSION= 0x0600 ) #define HB_HAS_INET_PTON #define HB_HAS_INET_NTOP # endif # define HB_HAS_SOCKADDR_STORAGE /* # define HB_HAS_INET6 */ # elif defined( __MINGW32__ ) # define HB_HAS_SOCKADDR_STORAGE # elif defined( __POCC__ ) !defined( __XCC__ ) # define HB_HAS_SOCKADDR_STORAGE # endif # define HB_IS_INET_NTOA_MT_SAFE ... Please, see the use of NTDDI_VERSION. Yes, NTDDI_VERSION is the (best? only?) way to detect platform SDK version. I think that yes .- http://msdn.microsoft.com/en-us/library/aa450087.aspx Even better. __MINGW32__ and __MINGW64__ they are both compiler 's built-in macros. Is defined in mingwce? IMO this is not relevant, there is no reason to be compiler specific here. This is general HB_OS_WIN issue. If you want to guard against WinCE, us HB_OS_WIN_CE Harbour macro. Sorry, I meant that if defined __MINGW64__ also is defined __MINGW32__ I don't know in wingwce. Yes, __MINGW32__ is defined in all mingw editions. (see in src\common\hbver.c) For x64 and WinCE we have HB_WIN_OS_64 and HB_OS_WIN_CE Harbour macros. [ Viktor Please could you send plain text posts, are much easier to read. ] Okay, sorry, I'm on gmail now, toggled it to plain text. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Hi Viktor, _WIN32_WINNT is nice, but it has other purpose. NTDDI_VERSION = maximum OS version supported by SDK/Windows-headers _WIN32_WINNT = OS version we want to target Okay, but if you remember my thread starting post .- IMHO the best solution is to define the version of Windows that supports the C compiler before compilation. For example, if your C compiler supports Vista: set HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600 http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx Some structures are defined only in the headers from one version of Windows other may change. IPv6 is supported from Windows Server 2003, Windows XP. Even calling functions dynamically is necessary data with which they work. It can make the binary work with earlier versions but the headers and the code should be protected by .- #if _WIN32_WINNT = 0x0501 ... #endif If not, we can have compile-time errors. Please, what do you think about this, comments? And we *force* _WIN32_WINNT or NTDDI_VERSION in hard code. If someone compiles Harbour with earlier versions of C compiler headers may have compile-time errors. IMHO we need a solution in to make-system and I'm not an expert on this. Best regards, -- Xavi El 28/02/2010 18:12, Viktor Szakáts escribió: On 2010 Feb 28, at 18:02, Xavi wrote: Hi Viktor, Yes, NTDDI_VERSION is the (best? only?) way to detect platform SDK version. The only problem is that MinGW does not use NTDDI_VERSION, it uses _WIN32_WINNT. At least in my versions of MinGW. :) Yes, unfortunately the problem with NTDDI_VERSION, is that it's not backward compatible solution (they introduces it quite late), and some 3rd party Windows headers set don't support it (yet). _WIN32_WINNT is nice, but it has other purpose. NTDDI_VERSION = maximum OS version supported by SDK/Windows-headers _WIN32_WINNT = OS version we want to target BTW, the values are also different, to make it simpler. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building Harbour on Windows.
Viktor, I think it's not that hard, I may be wrong but to respond quickly. I can call dynamically to GetAdaptersAddresses and in a nice Win7 is OK. But you can compile in your Win7 with MSVC++ 6.0 (it not say that _WIN32_WINNT is 0x0500 for compiler Harbour) and have compile-time errors. I can force _WIN32_WINNT to 0x0501 and assume that if exist GetAdaptersAddresses in system dlls the functionality is Ok but really you don't have IP_ADAPTER_ADDRESSES estruct in your headers and I can not give include the structure in my code. IMHO this applies to all C compilers and documented by Microsoft and MinGW. Also avoid dynamically call basic functionality of ws2_32.dll like getaddrinfo, freeaddrinfo, getnameinfo, inet_ntop, inet_pton, knock if inet_ntoa is safe, all IPv6, etc ... Ok I can detect that is MSVC++ 6.0 and protected by something _MSC_VER == 1200, also assume that is not supported but requires knowledge about all versions of compilers and may have other SDK installed that is not the last and obviously all called dynamically. Now __WATCOMC__ users must specify NTDDI_VERSION and TCPV40HDRS if not the functionality is canceled. Besides it's quite difficult to discuss this without knowing what do you exactly want to make here. Maybe you could post some code (patch) to see where you're standing at ATM. Unfortunately I lose more time with all these issues that programming something concrete but I would assume and hope that this is good for everyone. :) Best regards, -- Xavi El 28/02/2010 19:09, Viktor Szakáts escribió: NTDDI_VERSION = maximum OS version supported by SDK/Windows-headers _WIN32_WINNT = OS version we want to target Okay, but if you remember my thread starting post .- IMHO the best solution is to define the version of Windows that supports the C compiler before compilation. For example, if your C compiler supports Vista: set HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600 http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx Some structures are defined only in the headers from one version of Windows other may change. IPv6 is supported from Windows Server 2003, Windows XP. Even calling functions dynamically is necessary data with which they work. It can make the binary work with earlier versions but the headers and the code should be protected by .- #if _WIN32_WINNT= 0x0501 ... #endif If not, we can have compile-time errors. Please, what do you think about this, comments? And we *force* _WIN32_WINNT or NTDDI_VERSION in hard code. If someone compiles Harbour with earlier versions of C compiler headers may have compile-time errors. IMHO we need a solution in to make-system and I'm not an expert on this. Sorry but I don't understand this thread anymore. IMO the solution is simple: If you need to use Windows API features which are not supported in all Windows versions: 1) make it using dynamic calls, so binary won't break if feature not available 2) detect OS header version (only this may need compiler specific solutions) 3) force target OS version by defining _WIN32_WINNT before windows.h, if target OS version is known to be supported by headers If only constants are missing you can replace 2) + 3) with simple manual definition of those missing constants. I don't see any need for a make-level solution. All macros can be defined from source. Why is it better to define them on make level? Besides it's quite difficult to discuss this without knowing what do you exactly want to make here. Maybe you could post some code (patch) to see where you're standing at ATM. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Building Harbour on Windows.
Hi all, IMHO the best solution is to define the version of Windows that supports the C compiler before compilation. For example, if your C compiler supports Vista: set HB_USER_CFLAGS=-D_WIN32_WINNT 0x0600 http://msdn.microsoft.com/en-us/library/aa383745%28VS.85%29.aspx Some structures are defined only in the headers from one version of Windows other may change. IPv6 is supported from Windows Server 2003, Windows XP. Even calling functions dynamically is necessary data with which they work. It can make the binary work with earlier versions but the headers and the code should be protected by .- #if _WIN32_WINNT = 0x0501 ... #endif If not, we can have compile-time errors. Please, what do you think about this, comments? -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13982] trunk/harbour
Lorenzo, Try this, if may help you .- Procedure Main() Local ID_TAB_AGENTI := TAB_AGENTI Local ID_TAB_CODDSP := TAB_AGENTI Local cSql := select 'Hello' as fld Local cAnnDsp := 2000 Local cFrmSQL #pragma __cstream|cFrmSQL:=%s select ( select substr( crectab, 1, 20 ) as crectab from tabtab where ctiptab = %1$t and ckeytab = ccodage order by 1 ) as cdesage, ; sum( case when ( select substr( crectab, 35, 1 ) from tabtab where ctiptab = %2$t and ckeytab = ccoddsp ) = '' or ( select substr( crectab, 35, 1 ) from tabtab where ctiptab = %2$t and ckeytab = ccoddsp ) is null then nimpdsp else 0 end) as ntotfat0, sum( case when ( select substr( crectab, 35,1 ) from tabtab where ctiptab = %2$t and ckeytab = ccoddsp ) = '1' then nimpdsp else 0 end) as ntotfat1,sum(nimpdsp) as ntotdsp, %3$s from tabtotdsp left join tabtab on tabtab.ctiptab= %2$t and ccoddsp=tabtab.ckeytab where canndoc = %4$t #pragma __endtext ? sql_Sprintf( cFrmSQL, ID_TAB_AGENTI, ID_TAB_CODDSP, cSql, cAnnDsp ) Wait return It seems to me that does the same and more. HTH -- Xavi El 24/02/2010 21:03, Lorenzo Fiorini escribió: On Wed, Feb 24, 2010 at 8:10 PM, Viktor Szakáts It would be good to hear from you (as the only known user of this feature) what is the benefit of using it, f.e. over #pragma __cstream. Maybe there exists better solution to keep support for it, than build-time or compile-time switch. For me it is not a compatibility issue but an absolute requirement. All my code counts on it and will ever do. It would be completely INSANE to write sql statements without HB_PP_MULTILINE. This is a small example: ... cSql := select ( select substr( crectab, 1, 20 ) as crectab ; from tabtab where ctiptab = ' + ID_TAB_AGENTI + ' ; and ckeytab = ccodage order by 1 ) as cdesage, ; sum( case when ( select substr( crectab, 35, 1 ) from tabtab ; where ctiptab = ' + ID_TAB_CODDSP + ' and ckeytab = ccoddsp ) = '' or ; ( select substr( crectab, 35, 1 ) from tabtab ; where ctiptab = ' + ID_TAB_CODDSP + ' and ckeytab = ccoddsp ) is null ; then nimpdsp ; else 0 end) as ntotfat0, ; sum( case when ( select substr( crectab, 35, 1 ) from tabtab ; where ctiptab = ' + ID_TAB_CODDSP + ' and ckeytab = ccoddsp ) = '1' ; then nimpdsp ; else 0 end) as ntotfat1, sum(nimpdsp) as ntotdsp,; + cSql + from tabtotdsp ; left join tabtab on tabtab.ctiptab= ' + ID_TAB_CODDSP + ' and ccoddsp=tabtab.ckeytab ; where canndoc = ' + cAnnDsp + ' ... best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
Hi Xavi, _Przemek, thank you very much for answering me directly_ It's is possible. Just like many other things which still do not exists in MS-Windows and we will have to wait next 10 years until MS discover them and add some support for it in WinSOCK.X.Y.Z which will work correctly in version X.Y.Z + N. There is only one question: Why we should add such things? The fact that sth is possible on some platforms does not mean that it has to be implemented. [...] Why you added HB_SOCKET_IFINFO_GATEWAY? What programs do you plan to write which will need such information? How do you know that which gateway belongs to each IP address? It's possible that aliases uses different gateways (at least in normal systems). I do not see any code which tries to bind gateway addresses with IP addresses so HB_SOCKET_IFINFO_GATEWAY contains correct information only when the same gateway is used by all aliases. I did it to make something new, not important in itself. MS-Windows does not have interface names as other hosts. AFAIR windows ports of some *nix tools like ifconfing used IP address as interface name so I decided to use the same. You added code which replace this IP addres with localhost string for LOOPBACK interfaces. Why? AFAIK in Windows the adapter name is one GUID exept localhost. Do you know that it's possible to have more then one LOOPBACK interface with different addresses? Yes and with the appropriate GUID adapter name. [...] hb_arrayGetC() returns address to dynamically allocated memory block which should be freed by hb_itemFreeC(). Now this code causes memory leak. Is iphlpapi.dll loaded by application at startup and keep alive for whole application running time? THANK YOU!!! for test and respond. Yes, I've a pretty hb_out.log report compiling with HB_FM_STATISTICS. Remember what means a draft code. :) You can see the interest of people about it because your sample PRG code and my sample no presents nothing in Windows. If not then storing pointer to GetAdaptersInfo() in static variable seems to be a little bit risk because such address may change. I think that this may also happen with the system dlls. Remember my post about this .- http://lists.harbour-project.org/pipermail/harbour/2010-February/032151.html BTW in which Windows version GetAdaptersInfo() was added? This code does not detect aliases. It has to be redesigned to eliminate them. Well, what do you suggest? Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Przemek,
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
No problem, I've done MS-Windows only implementation that also includes MACs
address.
aAdapters == { {cType, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter} }
So if you provides functions names, file names, in short where putting it, I
think that don't it cost me a lot of work. :)
Best regards,
Xavi
El 19/02/2010 11:36, Przemysław Czerpak escribió:
On Fri, 19 Feb 2010, Przemysław Czerpak wrote:
Hi,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ifname,ifaddr,bcastaddr,netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
Looking at header files seems that I can port it to OS2 (WATCOM) and
DOS-WATTCP but it will not work in MS-Windows builds so it will be
necessary to create independent implementation giving similar
functionality for this system only.
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
I think it's public.
http://groups.google.us/group/comp.lang.xharbour/browse_thread/thread/8a9348df065610fc#b8c7e71c405b7e52
Obviously adapted to the new Harbour.
Best regards,
Xavi
El 19/02/2010 19:11, Viktor Szakáts escribió:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Hi Viktor,
Okay. I thought about it but waiting to see what says or does Przemek.
Hope the development list work, because the other participant are off topic.
Best regards,
Xavi
El 19/02/2010 20:06, Viktor Szakáts escribió:
Okay. Probably it would be better to change to load
the .dll dynamically, unless we want add this new
system .dll to default system lib libs for the sake
of one function. It's rarely used functionality, so
this would save all Harbour apps some load time and
memory consumption.
Brgds,
Viktor
On 2010 Feb 19, at 19:40, Xavi wrote:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
I think it's public.
http://groups.google.us/group/comp.lang.xharbour/browse_thread/thread/8a9348df065610fc#b8c7e71c405b7e52
Obviously adapted to the new Harbour.
Best regards,
Xavi
El 19/02/2010 19:11, Viktor Szakáts escribió:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlockHB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: error C2485 compiling hvm.c with vce 2007
Antonio, Seems that Windows CE does not support the __declspec(thread) attribute. But you're using HB_STACK_MACROS, remember .- http://lists.harbour-project.org/pipermail/harbour/2009-December/029344.html -- Xavi El 19/02/2010 3:41, Antonio Linares escribió: More on the C2485 error compiling with Microsoft Windows CE 6.x SDK cl.exe: We have found where the error is coming from. It was not a define: hb_stack_ptr is defined as: HB_TLS_ATTR PHB_STACK hb_stack_ptr = NULL; HB_TLS_ATTR is translated into __declspec( thread ) and that may be causing a mangled name for the variable name that makes the compiler itself to error. If we remove (just for a test) HB_TLS_ATTR from estack.c (line 93) and from hbstack.h (line 200) then those errors go away. Obviously that is not a solution but take us closer to find it. regards, Antonio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
[ Not work the development mailing list ]
Hi Viktor,
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#include Iphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
Best regards,
Xavi
El 19/02/2010 16:02, Viktor Szakáts escribió:
Hi Xavi, Przemek,
To have similar features for all platform, either we
should support MAC address on non-win platforms, or
(if this is not possible or not portable) we should
move win-only MAC support to some additional hbwin
function.
Brgds,
Viktor
On 2010 Feb 19, at 15:56, Xavi wrote:
[ Seem that not work the development mailing list ]
Przemek,
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
No problem, I've done MS-Windows only implementation that also includes MACs
address.
aAdapters == { {cType, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter} }
So if you provides functions names, file names, in short where putting it, I
think that don't it cost me a lot of work. :)
Best regards,
Xavi
El 19/02/2010 11:36, Przemysław Czerpak escribió:
On Fri, 19 Feb 2010, Przemysław Czerpak wrote:
Hi,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ifname,ifaddr,bcastaddr,netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
Looking at header files seems that I can port it to OS2 (WATCOM) and
DOS-WATTCP but it will not work in MS-Windows builds so it will be
necessary to create independent implementation giving similar
functionality for this system only.
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Viktor, It's nice. About Character Data. If the encode is UNICODE, ASCII, ANSI, NULL is the terminator: only RAW can be 0 in the data. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
We need new HB_ITEM type, separate UNICODE OT: It's possible to preserve a flag to mark SQL NULL. An ITEM can be DATE but be NULL, boolean logic is different. At least count on it. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
it can be implemented without touching HVM and we Ok. Sorry for OT :) [ Remember that HB_IT_TIMESTAMP, HB_IT_DATETIME, could also be implemented without touching HVM ] Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13873] trunk/harbour
Hi Przemek,
* harbour/contrib/hbwin/wapi_winbase.c
% optimized GetProcAddress() calls to store function addresses
in static variables
Ok. I don't like because it's not a conventional programming, more
sophisticated IMO.
Break the reports of dependence and some installers can make use of them.
.def_getlongpathna...@12; .scl2; .type 32; .endef
Also I thought that could have problems with optimizations and more slower but if I'm no wrong, seems don't have this problems
and is just as fast (I attached test). So I surrender to the evidence. :)
What would be the rule, all functions out of ( _WIN32_WINNT 0x0500 ) should
call dynamically?
Best regards,
Xavi
#define CSIDL_ADMINTOOLS0x0030 /* username\Start
Menu\Programs\Administrative Tools */
#define MAX_PATH 260
PROCEDURE Main()
LOCAL cData, i, nSec
cData := Space( MAX_PATH )
DllCall( shell32.dll, NIL, SHGetFolderPath, 0, CSIDL_ADMINTOOLS, 0, 0,
@cData )
cData := Trim( cData )
? [ + cData + ]
cData := StrTran( cData, Chr(0), '\' ) // Change terminating null character
by '\'
? [ + cData + ]
wapi_SetLastError( 0 )
wapi_GetShortPathName( cData, @cData )
if( wapi_GetLastError() == 0 )
? ShortName [ + cData + ]
wapi_GetLongPathName( cData, @cData )
? LongName [ + cData + ]
? ==
nSec := Seconds()
for i := 0 to 1 // 3 for test
wapi_GetShortPathName( cData, @cData )
// ? ShortName [ + cData + ]
wapi_GetLongPathName( cData, @cData )
// ? LongName [ + cData + ]
next
? Delay Not :, Seconds() - nSec
nSec := Seconds()
for i := 0 to 1 // 3 for test
wapi_GetShortPathName( cData, @cData )
// ? ShortName [ + cData + ]
mk_GetLongPathName( cData, @cData )
// ? LongName [ + cData + ]
next
? Delay Opt :, Seconds() - nSec
? ==
else
? Error, wapi_GetLastError()
endif
WAIT
RETURN
/*
* $Id: wapi_winbase.c 13873 2010-02-14 14:18:13Z druzus $
*/
/*
* Harbour Project source code:
* Windows API functions (winbase)
*
* Copyright 2009 Viktor Szakats (harbour.01 syenar.hu)
* www - http://www.harbour-project.org
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
* Boston, MA 02111-1307 USA (or visit the web site http://www.gnu.org/).
*
* As a special exception, the Harbour Project gives permission for
* additional uses of the text contained in its release of Harbour.
*
* The exception is that, if you link the Harbour libraries with other
* files to produce an executable, this does not by itself cause the
* resulting executable to be covered by the GNU General Public License.
* Your use of that executable is in no way restricted on account of
* linking the Harbour library code into it.
*
* This exception does not however invalidate any other reasons why
* the executable file might be covered by the GNU General Public License.
*
* This exception applies only to the code released by the Harbour
* Project under the name Harbour. If you copy code from other
* Harbour Project or Free Software Foundation releases into a copy of
* Harbour, as the General Public License permits, the exception does
* not apply to the code that you add in this way. To avoid misleading
* anyone as to the status of such modified files, you must delete
* this exception notice from them.
*
* If you write modifications of your own for Harbour, it is your choice
* whether to permit this exception to apply to your modifications.
* If you do not wish that, delete this exception notice.
*
*/
/* Version with name declarate
MK_GETLONGPATHNAME
Only for test re-define _WIN32_WINNT [jarabal] */
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#include hbwapi.h
#include hbapierr.h
/* For SetErrorMode() */
#if defined( HB_OS_WIN_CE )
#include hbwince.h
#endif
HB_FUNC( WAPI_GETCOMMANDLINE )
{
HB_RETSTR( GetCommandLine() );
}
HB_FUNC( WAPI_GETCURRENTPROCESS )
{
wapi_ret_HANDLE( GetCurrentProcess() );
}
HB_FUNC( WAPI_GETCURRENTPROCESSID )
{
hb_retnint( GetCurrentProcessId() );
}
HB_FUNC( WAPI_GETCURRENTTHREAD )
{
wapi_ret_HANDLE( GetCurrentThread() );
}
HB_FUNC( WAPI_WAITFORSINGLEOBJECT )
{
DWORD
Re: [Harbour] SF.net SVN: harbour-project:[13865] trunk/harbour
Hi Viktor, There is GPF when trying it without length. (replace hb_parclen() with -1 in hb_u32ret() calls) Any idea why? Sorry, I don't have GPG with 13873 in ANSI/UNICODE with -1 .- #define CSIDL_ADMINTOOLS0x0030 /* username\Start Menu\Programs\Administrative Tools */ #define MAX_PATH 260 PROCEDURE Main() LOCAL cData cData := Space( MAX_PATH ) DllCall( shell32.dll, NIL, SHGetFolderPath, 0, CSIDL_ADMINTOOLS, 0, 0, @cData ) ? [ + cData + ] cData += '\' ? [ + cData + ] WAIT RETURN The result is Ok .- [C:\Documents and Settings\Xavi\Menú Inicio\Programas\Herramientas administrativas] [C:\Documents and Settings\Xavi\Menú Inicio\Programas\Herramientas administrativas\] In Spanish this requires UNICODE due to accent in word Menú. :) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13856] trunk/harbour
Thanks Viktor,
IMHO before we need to know how to set the minimum version of Windows.
Usually this is done by defining in the final project _WIN32_WINNT.
So the code would look something like this .-
...
#if ( _WIN32_WINNT = 0x0500 ) ! defined( HB_OS_WIN_CE )
# define HBDI_L_FGPN( p1, p2, p3 ) GetLongPathName( p1, p2, p3 )
# define HBDI_S_FGPN( p1, p2, p3 ) GetShortPathName( p1, p2, p3 )
#else
# define HBDI_L_FGPN( p1, p2, p3 ) GetShortPathName( p1, p2, p3 )
# define HBDI_S_FGPN( p1, p2, p3 ) GetShortPathName( p1, p2, p3 )
#endif
static DWORD hbi_GetShortLongPathName( HB_BOOL bLong )
{
void * hPath;
DWORD length = 0;
LPCTSTR lpszInPath = HB_PARSTR( 1, hPath, NULL );
if( lpszInPath )
{
if( HB_ISBYREF( 2 ) )
{
TCHAR buffer[ HB_PATH_MAX ];
DWORD cchBuffer = ( DWORD ) HB_SIZEOFARRAY( buffer );
LPTSTR lpszOutPath = buffer;
HB_BOOL fSize = HB_ISNUM( 3 );
if( fSize ) /* size fixed by user */
{
cchBuffer = ( DWORD ) hb_parnl( 3 );
if( cchBuffer == 0 )
lpszOutPath = NULL;
else if( cchBuffer ( DWORD ) HB_SIZEOFARRAY( buffer ) )
lpszOutPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR ) );
}
length = bLong ? HBDI_L_FGPN( lpszInPath, lpszOutPath, cchBuffer ) :
HBDI_S_FGPN( lpszInPath, lpszOutPath, cchBuffer ) ;
if( !fSize length cchBuffer ) /* default buffer size was too
small */
{
cchBuffer = length;
lpszOutPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR ) );
length = bLong ? HBDI_L_FGPN( lpszInPath, lpszOutPath, cchBuffer ) :
HBDI_S_FGPN( lpszInPath, lpszOutPath, cchBuffer ) ;
}
hbwapi_SetLastError( GetLastError() );
HB_STORSTRLEN( lpszOutPath, length cchBuffer ? 0 : length, 2 );
if( lpszOutPath lpszOutPath != buffer )
hb_xfree( lpszOutPath );
}
else
{
length = bLong ? HBDI_L_FGPN( lpszInPath, NULL, 0 ) :
HBDI_S_FGPN( lpszInPath, NULL, 0 ) ;
hbwapi_SetLastError( GetLastError() );
}
}
hb_strfree( hPath );
return length;
}
HB_FUNC( WAPI_GETLONGPATHNAME )
{
#if ( _WIN32_WINNT = 0x0500 ) ! defined( HB_OS_WIN_CE )
hb_retnl( hbi_GetShortLongPathName( HB_TRUE ) );
#else
hbwapi_SetLastError( ERROR_INVALID_FUNCTION );
hb_retnl( 0 );
#endif
}
HB_FUNC( WAPI_GETSHORTPATHNAME )
{
hbi_GetShortLongPathName( HB_FALSE );
}
...
I think we can not fix this definition inside Harbor should be passed by the
user.
What do you think about this?
Best regards,
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13856] trunk/harbour
Hi Viktor, Another method, and this is what we use consistently in Harbour, is to #define _WIN32_WINNT to 0x0500. IMHO this is not good because we may incorporate, now or in the future, functionality of XP, W7 ... Though probably we should rather use GetProcAddress() for GetLongPathName() to not break apps running on older Windows versions. It's more slower and broken the reports of dependences because is called (anonymous) dynamic. It's nice for something occasional but not for a wrapper to OS API, IMO. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13865] trunk/harbour
Hi Viktor, I would suggest that if type of string param not is RAW, not use hb_stor*len use hb_stor* This would avoid the possible inclusion of terminating null character. I also recommend the use of a new our macro in exclusive HB_TEXT for UNICODE literals. Or at least change the current definition of HBTEXT to avoid problems. ... #if defined( UNICODE ) || defined( HB_OS_WIN_CE ) #define HBTEXT( x ) TEXT( x ) #else #define HBTEXT( x ) x #endif ... [ And out of context :) Remember that in API DLLs, the name of function is finish in A or W. Not enough that the string is ANSI or UNICODE. ] Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13865] trunk/harbour
Hi Przemek, You're right if HBTEXT is only for use inside of GetProcAddress. It has to give 8bit ASCII text in all desktop windows. IMHO for this reason if the code is for all desktop windows and for WinCE is better to use GetProcAddressA. [ Remember the A final for ASCII ] ... #if defined( HB_OS_WIN_CE ) #define GetProcAddress GetProcAddressA #endif ... And avoid the confusion because don't look any macro for UNICODE literals inside calls to GetProcAddress. Also I think it simplifies other things, as always is LPCSTR. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13850] trunk/harbour
Viktor thank you very much, It's a wonderful work and a great demostrción that all or almost anything is possible in C. My heartfelt congratulations on this. Best regards, Xavi El 12/02/2010 12:27, vszak...@users.sourceforge.net escribió: Revision: 13850 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13850view=rev Author: vszakats Date: 2010-02-12 11:27:02 + (Fri, 12 Feb 2010) Log Message: --- 2010-02-12 12:20 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/hbwin.ch + Added HB_WIN_DLL_CALLCONV_* macros. (so far only privately defined inside .c code) + Added HB_WIN_DLL_CTYPE_* macros. (so far only privately defined inside .c code) + Reworked HB_WIN_DLL_CTYPE_* macro values. INCOMPATIBLE. Since they weren't previously documented, this should not be a breakage, pls report it if this is a problem. ! Fixed .ch syntax to also work in .c files. * contrib/hbwin/hbwin.h * contrib/hbwin/legacycd.c * contrib/hbwin/win_dll.c * contrib/hbwin/tests/testdll.prg * Using hbwin.ch for callconv and C type constants. + Added public low-level interface: hbwin_dllCall(). This has provision for exact parameter type specification. * Changed Harbour level functions to use new public interface hbwin_dllCall(). + Moved CALLDLL(), CALLDLLBOOL(), CALLDLLTYPED() to legacy source. * HB_DLLEXEC structure made private to XPP compatibility section. + Added new WIN_DLLCALL() API. This can replace all old CALL*() function and give more flexibility. Its first parameter is an optional array, which can specify calling convention (it was fixed in old implementation), return type and UNICODE swicth, plus it has provision to specify parameter types, too. + Changed test app to use new WIN_DLLCALL() API. * hb_getprocaddress() made public (but not exported) and renamed to hbwin_getprocaddress(). * config/wce/mingwarm.mk * config/win/mingw.mk - Deleted hack to always add frame buffer for hbwin. It's not necessary anymore. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/wce/mingwarm.mk trunk/harbour/config/win/mingw.mk trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/legacycd.c trunk/harbour/contrib/hbwin/tests/testdll.prg trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13850] trunk/harbour
Hi Viktor,
It still needs some closer testing, as double/float/int64
handling wasn't tested, so things like DWORD order might be
off, also int64 support needs work. Anyway, without ASM and
with fundamentals in place, the scope of these functions is
now broader, and also easier to understand, so I hope more
ppl will be willing to touch it or just use it.
Ok. I would suggest two things .-
One is a minor change to remove warnings (attached patch).
Another: There would fit PRG copy items to avoid change if parameters are not
passed by reference.
Sample .-
...
? CALLDLL: , CallDll( GetProcAddress( hDLL, SHGetFolderPath ), 0,
CSIDL_ADMINTOOLS, 0, 0, cData ) // WRONG
? cData: , cData
...
I was also thinking to create a way to describe and pass
C level function skeletons as string to HB_DLLCALL(),
which could then decide about the precise details, make
necessary conversions, etc.
F.e.:
HB_DLLCALL( h, __cdecl _int64 AnyCall( int, long, double ), nPar1, nPar2,
nPar3 )
or something Windows specific (since we're in hbwin lib yet):
HB_DLLCALL( h, WINAPI DWORD SetSomething( LPTCSTR ), cHarbourString )
Such thing could make .dll calls very user-friendly.
It's over my C knowledge, but maybe someone will be able
to implement in the future.
I think that Przemek could say something. :)
[ It's a parser to C language with examples of rules on C interpreters. ]
Maybe I've spent the finish line and only need to interpret some key words in
the string.
But this don't substract that currently, it's very functional IMO.
Best regards,
Xavi
Index: win_dll.c
===
--- win_dll.c (revision 13851)
+++ win_dll.c (working copy)
@@ -672,9 +672,9 @@
for( tmp = 0; tmp iParams; ++tmp )
{
-HB_U32 r1;
-HB_U32 r2;
-HB_BOOL b64;
+HB_U32 r1 = 0;
+HB_U32 r2 = 0;
+HB_BOOL b64 = HB_FALSE;
wcall.pArg[ tmp ].bByRef = HB_ISBYREF( iFirst + tmp );
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13850] trunk/harbour
Hi Viktor,
Should be fixed now. (Though for me only one of them
gave warning, pls tell if it's still wrong).
Yes you're right.
I'm sorry, I do too many things on automatic and not is good. :)
I see what you mean. I don't know the most optimal way
to solve that. ...
Look at the patch if it can help you, only win32.
Actually, such function could be written as .prg
code by anyone. Now the low-level logic is there,
[ ... ]
Ok. I see, it's nice.
Best regards,
Xavi
Index: win_dll.c
===
--- win_dll.c (revision 13852)
+++ win_dll.c (working copy)
@@ -249,6 +249,7 @@
int iFirst;
int * piArgTypeReq;
int * piArgType;
+ PHB_ITEM * pItmCpy;
HB_WINARG * pArg;
} HB_WINCALL, * PHB_WINCALL;
@@ -846,24 +847,28 @@
if( iParams )
{
+wcall.pItmCpy = ( PHB_ITEM * ) hb_xgrab( iParams * sizeof(
PHB_ITEM ) );
wcall.pArg = ( HB_WINARG * ) hb_xgrab( iParams * sizeof( HB_WINARG
) );
wcall.piArgType = ( int * ) hb_xgrab( iParams * sizeof( int ) );
memset( wcall.pArg, 0, iParams * sizeof( HB_WINARG ) );
}
else
{
+wcall.pItmCpy = NULL;
wcall.pArg = NULL;
wcall.piArgType = NULL;
}
for( tmp = 0; tmp iParams; ++tmp )
{
-PHB_ITEM pParam = hb_param( iFirst + tmp, HB_IT_ANY );
+PHB_ITEM pParam;
HB_U32 r1 = 0;
HB_U32 r2;
HB_BOOL b64;
+hb_itemCopy( pParam = hb_itemNew( NULL ), hb_param( iFirst + tmp,
HB_IT_ANY ) );
+wcall.pItmCpy[ tmp ] = hb_itemUnShare( pParam );
wcall.piArgType[ tmp ] = wcall.piArgTypeReq ? wcall.piArgTypeReq[
tmp ] : HB_WIN_DLL_CTYPE_DEFAULT;
if( wcall.piArgType[ tmp ] == HB_WIN_DLL_CTYPE_DEFAULT )
@@ -1329,8 +1334,14 @@
}
for( tmp = 0; tmp iParams; ++tmp )
+ {
+hb_itemRelease( wcall.pItmCpy[ tmp ] );
hb_strfree( wcall.pArg[ tmp ].hString );
+ }
+ if( wcall.pItmCpy )
+hb_xfree( wcall.pItmCpy );
+
if( wcall.pArg )
hb_xfree( wcall.pArg );
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor, That can work, but it means we don't support int64/double parameters and int64/double/float/char return values anymore. Currently we do, so maybe it'd be good to take care of it. We should also support both cdecl and stdcall versions. Yes I know, this is not perfect. Also I just think, that in C, we can not *force* (yes or yes) the use of CPU registers AFAIK. IMHO this solution could work with majority calls, to the rest is easier and safer to make a private/local wrapper. So I think that's good if it works with other compilers because the alternative is keep all hbwin outside present and future optimizations for this ASM hard code. Perhaps it's better separate this function to other optional library. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13841] trunk/harbour
Hi Przemek,
Ok, I'll do it ...more slowly :)
Best regards,
--
Xavi
El 11/02/2010 12:48, Przemysław Czerpak escribió:
On Thu, 11 Feb 2010, jara...@users.sourceforge.net wrote:
Hi Xavi,
2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
* contrib/hbwin/wapi_winbase.c
+ Added wapi_GETSHORTPATHNAME()
Thank you very much. Just only few notes.
WAPI_* functions should be as closed to original implementation
as possible. We can introduce some small extensions and parameter
validation (it's even suggested) using additional information we
have due to Harbour item types but we should not change or ignore
valid parameters. In this case passing 0 as 3-rd parameter is ignored
Also the buffer is 1 or 3 in UNICODE mode bytes greater then request
by user. If programmer not precisely check the implementation details
then he can be seriously confused by the results.
If wapi_GETSHORTPATHNAME() supports the following parameters:
wapi_GETSHORTPATHNAME(cLongName [, @shortName [,nMaxSize ] ] )
-nShortLenght
then the implementation should follow it.
I also suggest to eliminate double call to GetShortPathName() if possible.
In some cases it can be quite expensive i.e. network volumes.
Below is your code a little bit modified to respect above conditions.
I think that we should add also wapi_GETLONGPATHNAME() and
wapi_GETFULLPATHNAME()
Can you implement them too?
best regards,
Przemek
HB_FUNC( WAPI_GETSHORTPATHNAME )
{
void * hLongPath;
DWORD length = 0;
LPCTSTR lpszLongPath = HB_PARSTR( 1,hLongPath, NULL );
if( lpszLongPath )
{
if( HB_ISBYREF( 2 ) )
{
TCHAR buffer[ HB_PATH_MAX ];
DWORD cchBuffer = ( DWORD ) HB_SIZEOFARRAY( buffer );
LPTSTR lpszShortPath = buffer;
HB_BOOL fSize = HB_ISNUM( 3 );
if( fSize )/* the size of buffer is limited by user */
{
cchBuffer = ( DWORD ) hb_parnl( 3 );
if( cchBuffer == 0 )
lpszShortPath = NULL;
else if( cchBuffer ( DWORD ) HB_SIZEOFARRAY( buffer ) )
lpszShortPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR
) );
}
length = GetShortPathName( lpszLongPath, lpszShortPath, cchBuffer );
if( !fSize length cchBuffer ) /* default buffer size was too
small */
{
cchBuffer = length;
lpszShortPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR ) );
length = GetShortPathName( lpszLongPath, lpszShortPath, cchBuffer
);
}
hbwapi_SetLastError( GetLastError() );
HB_STORSTRLEN( lpszShortPath, length cchBuffer ? 0 : length, 2 );
if( lpszShortPath lpszShortPath != buffer )
hb_xfree( lpszShortPath );
}
else
{
length = GetShortPathName( lpszLongPath, NULL, 0 );
hbwapi_SetLastError( GetLastError() );
}
}
hb_retnl( length );
hb_strfree( hLongPath );
}
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor, I can easily implement pure .c win32 .dll call support which drops support for int64/double parameters and int64/double/float return values. I'd also guess they are not very widely used, so it's probably not a big loss. I agree. If need it, is better to have a specific wrapper. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor,
To avoid ASM the compiler needs to know the call and sizes at compile time.
Too many combinations for a job that may not be perfect and maybe unused.
It's possible to simplify overwriting the stack with struct of byte array more call more choice but I think with some
optimizations will have problems: I really don't like either solution.
Otherwise I think that can be used win64 implement also for win32 with some
modifications.
What do you think of the patch attached (names are irrelevant)?
Also I would suggest copying items parameters inside HB_WINARG to avoid changes
if they are not passed by reference.
Best regards,
Xavi
El 09/02/2010 14:49, Viktor Szakáts escribió:
Hi,
From this point it's users responsibility to
pass parameters properly.
Ok. Next topic: coverage of potential C .dll functions.
IMO it's unworkable cover functions of n parameters with n size,
seems reasonable to restrict to 15 the number of parameters.
This limit already exists, and it should be enough for
a start. Anyway, once the scheme is developed, it will be
easy to extend if it's worth it or required. For vast
majority of cases 15 is enough.
Currently only covering sizes of 4, 8 bytes in win32 and 8 bytes in win64.
This means that calls to PosibleDLLfunc( WORD wPar, BYTE bPar ) are not
possible.
4 and 8 byte parameters are enough for all win32
calling conventions. So it's possible to pass BYTE
already.
How many types of data have to be supported?
win32: 4 or 8 for arguments, return value can be 4, 8 bytes or double/float.
plus each in two variations: cdecl or stdcall (winapi)
win64: 8 for argument, return value is also 8 bytes
BYTE, WORD, DWORD, PVOID, float, double.
For win64 current solution covers all combinations, as
there is a much simpler calling convention there, see:
http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx
Brgds,
Viktor
Index: win_dll.c
===
--- win_dll.c (revision 13835)
+++ win_dll.c (working copy)
@@ -61,7 +61,7 @@
#include hbapiitm.h
#include hbvm.h
-#if !defined( __CYGWIN__ ) !defined( HB_NO_ASM )
+#if !defined( __CYGWIN__ )
/* ==
* DynaCall support comments below
@@ -156,8 +156,14 @@
#pragma pack()
+#define HB_OS_WIN_64_32
+
#if ! defined( HB_OS_WIN_64 )
+# define HB_U64 HB_U32
+#endif
+#if ! defined( HB_OS_WIN_64_32 )
+
static HB_DYNRETVAL hb_DynaCall( int iFlags, FARPROC lpFunction, int nArgs,
HB_DYNPARAM Parm[], void * pRet, int nRetSiz )
{
/* Call the specified function with the given parameters. Build a
@@ -384,7 +390,7 @@
#define _DLLEXEC_MAXPARAM 15
-#if defined( HB_OS_WIN_64 )
+#if defined( HB_OS_WIN_64_32 )
typedef struct
{
@@ -554,7 +560,7 @@
if( iRtype == 0 )
iRtype = CTYPE_UNSIGNED_LONG;
-#if defined( HB_OS_WIN_64 )
+#if defined( HB_OS_WIN_64_32 )
{
HB_WINCALL wcall;
@@ -575,7 +581,7 @@
wcall.pArg = NULL;
for( tmp = 0; tmp iParams; ++tmp )
-wcall.pArg[ tmp ].bByRef = HB_ISBYREF( iFirst + 1 + tmp );
+wcall.pArg[ tmp ].bByRef = HB_ISBYREF( iFirst + tmp );
switch( iParams )
{
@@ -601,7 +607,7 @@
{
if( wcall.pArg[ tmp ].bByRef )
{
- switch( HB_ITEM_TYPE( hb_param( iFirst + 1 + tmp, HB_IT_ANY ) )
)
+ switch( HB_ITEM_TYPE( hb_param( iFirst + tmp, HB_IT_ANY ) ) )
{
case HB_IT_LOGICAL:
hb_storl( wcall.pArg[ tmp ].nValue != 0, tmp );
@@ -900,7 +906,7 @@
if( pbUNICODE )
*pbUNICODE = HB_FALSE;
-#if defined( HB_OS_WIN_64 ) /* TOFIX: Remove this when UNICODE support gets
implemented for non-Win64. */
+#if defined( HB_OS_WIN_64_32 ) /* TOFIX: Remove this when UNICODE support gets
implemented for non-Win64. */
#if defined( UNICODE )
if( ! lpFunction szProc ) /* try with WIDE suffix? */
{
@@ -1074,4 +1080,4 @@
hb_DllExec( DC_CALL_STDCALL, hb_parni( 2 ), ( FARPROC ) hb_parptr( 1 ),
NULL, hb_pcount(), 3 );
}
-#endif /* HB_OS_WIN !__CYGWIN__ !HB_NO_ASM */
+#endif /* HB_OS_WIN !__CYGWIN__ */
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] File names in dos/windows and Linux
Alex, Try with last SVN wapi_GetShortPathName( cLongPath, @cShortPath ) http://msdn.microsoft.com/en-us/library/aa364989%28VS.85%29.aspx HTH -- Xavi El 10/02/2010 15:47, Alex Strickland escribió: Bruno Luciani wrote: Which is the function that you say ? I have attached the code. It is a hack of the Harbour DIRECTORY() implementation. It may not be up to date with the code in SVN. I hope it helps. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor, You've introduced a new permanently set macro called HB_OS_WIN64_32, redefined a Harbour type (which should be avoided by all means) Is to work with win64 implementation in win32 with minimal changes. If the system is win32, not be used HB_U64 used HB_U32 to compile only win_dll.c and shifted parameter offset by one for reference types, It's a bad typo in win64. Try testdll.prg with MinGW in Win32, use CC_FLAGS .- -Wall -Wextra -march=i586 -mtune=pentiumpro -O3 -fomit-frame-pointer Sorry, I explain more later... :) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi all, From this point it's users responsibility to pass parameters properly. Ok. Next topic: coverage of potential C .dll functions. IMO it's unworkable cover functions of n parameters with n size, seems reasonable to restrict to 15 the number of parameters. Currently only covering sizes of 4, 8 bytes in win32 and 8 bytes in win64. This means that calls to PosibleDLLfunc( WORD wPar, BYTE bPar ) are not possible. How many types of data have to be supported? BYTE, WORD, DWORD, PVOID, float, double. -- Xavi El 08/02/2010 14:34, Viktor Szakáts escribió: ... its users job to passing parameters according to call specification of .dll function. Yes, but I think it's not only Harbour. Apply the patch attached to testdll.prg Could someone test that about xBase++ and/or xHarbour? Sorry, I can't see your point. It's a fact that GPF can be caused by passing wrongly formatted _raw_ parameters to C level functions. It's not Harbour's job to protect against it. Harbour's job is to create a working interface in pure .c, which makes it possible for users to pass these raw parameters from Harbour level to .c level. That's all. It's currently tackled together using ASM code, and this is the problem, because it's non-portable, CPU, compiler and compiler-setting dependent. From this point it's users responsibility to pass parameters properly. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi all, ... its users job to passing parameters according to call specification of .dll function. Yes, but I think it's not only Harbour. Apply the patch attached to testdll.prg Could someone test that about xBase++ and/or xHarbour? -- Xavi El 08/02/2010 10:54, Viktor Szakáts escribió: Hi, ... I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Yes, of course. ??? :) I can fix this without ASM, but a bad use of these functions always cause GPF. That would be the nicest. I guess protection against 'bad use' is not entirely possible, as its users job to passing parameters according to call specification of .dll function. Brgds, Viktor Index: testdll.prg === --- testdll.prg (revision 13328) +++ testdll.prg (working copy) @@ -69,7 +69,8 @@ ? cData DllUnload( hDLL ) - ? MsgBox:, DllCall( user32.dll, NIL, MessageBoxA, 0, Hello world!, Harbour sez, hb_bitOr( MB_OKCANCEL, MB_ICONEXCLAMATION, MB_HELP ) ) + /* Cause GPF [jarabal] */ + ? MsgBox:, DllCall( user32.dll, NIL, MessageBoxA, 0, MB_ICONEXCLAMATION /*Hello world!*/, Harbour sez, hb_bitOr( MB_OKCANCEL, MB_ICONEXCLAMATION, MB_HELP ) ) IF hb_FileExists( libcurl.dll ) hDLL := DllLoad( libcurl.dll ) @@ -96,17 +97,20 @@ hDLL := DllLoad( shell32.dll ) ? ValType( hDLL ): , ValType( hDLL ) cData := Space( MAX_PATH ) + cData := '' /* Cause GPF [jarabal] */ ? CALLDLLBOOL: , CallDllBool( GetProcAddress( hDLL, SHGetSpecialFolderPath ), 0, @cData, CSIDL_APPDATA, 0 ) ? @cData: , cData ? CALLDLL: , CallDll( GetProcAddress( hDLL, SHGetFolderPath ), 0, CSIDL_ADMINTOOLS, 0, 0, cData ) // WRONG ? cData:, cData cData := Space( MAX_PATH ) + cData := '123' /* Cause GPF [jarabal] */ ? CALDLL: , CallDll( GetProcAddress( hDLL, SHGetFolderPath ), 0, CSIDL_ADMINTOOLS, 0, 0, @cData ) ? @cData: , cData DllUnload( hDLL ) ? DLLCALL cData := Space( MAX_PATH ) + cData := 123 /* Cause GPF [jarabal] */ ? DllCall( shell32.dll, NIL, SHGetFolderPath, 0, CSIDL_ADMINTOOLS, 0, 0, @cData ) ? cData ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi, ... I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Yes, of course. ??? :) I can fix this without ASM, but a bad use of these functions always cause GPF. -- Xavi El 06/02/2010 18:37, Viktor Szakáts escribió: Hi Xavi, Very good point. I can add ugly hack to makefiles to always keep frame pointers for mingw in hbwin lib to make hb_DynaCall() function happy, but I wonder if it's possible to fix this function to not be sensitive on this setting. Any idea? Brgds, Viktor On 2010 Feb 6, at 17:41, Xavi wrote: Hi, I guess that is because hbwin is compiled with -fomit-frame-pointer. Try copy win_dll.c to the folder tests and compiled with .- hbmk2 testdll.prg win_dll.c -lstdc++ -debug Ok, I've only tested with gcc-dw2.exe -- Xavi El 06/02/2010 15:19, Fernando Athayde escribió: really don´t runs causes GPF i am using #include hbdll.ch hdll:=dllload(EZTW32.DLL) dllcall(hdll,DC_CALL_STD,TWAIN_SelectImageSource,::oFormCadastro:handle,) dllcall(hdll,DC_CALL_STD,TWAIN_AcquireToFilename,::oFormCadastro:handle,file.bmp) freelibrary(hdll) Best Regards, Fernando Athayde *De:* Itamar Linsitamarl...@gmail.com *Para:* harbour@harbour-project.org *Enviadas:* Sábado, 6 de Fevereiro de 2010 10:10:57 *Assunto:* [Harbour] MinGW dllcall function not run. Hi! sorry to insist on that but there is a possibility to make it work with him. I need to take MinGW. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Compiling with harbour -gc3 and -b .
Attache least possible changes to avoid .- warning: deprecated conversion from string constant to 'char*' Also without ( cast ) but more changes. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: SET() w/ p.o.c.
smu, set printer to ? set(24) // s/b , but set to LPT1 again Ok but it's also the default printer. Printer connected to port LPT1 in WoW and NTVDM DOS PC emulator under Windows. try .- FUNC MAIN() ? set(24) // Clipper is , Harbour is LPT1 set printer to (junk.txt) ? set(24) // junk.txt set printer to ? set(24) // s/b , but set to LPT1 again // set printer to LPT4 // set printer to set printer on ? Printed on default printer. RETURN -- Xavi El 03/02/2010 23:39, smu johnson escribió: FUNC MAIN() ? set(24) // Clipper is , Harbour is LPT1 set printer to (junk.txt) ? set(24) // junk.txt set printer to ? set(24) // s/b , but set to LPT1 again RETURN -- smu johnson smujohn...@gmail.com mailto:smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: SET() w/ p.o.c.
Well the program compiled in both Clipper and Harbour behaves differently on the same machine, same environment, in this case, Vista 32-bit. Hence an incompatibility. I think that could be changed to by default but maybe it's an advantage if you think that Harbour compile for other OS too. -- Xavi El 04/02/2010 5:15, smu johnson escribió: Well the program compiled in both Clipper and Harbour behaves differently on the same machine, same environment, in this case, Vista 32-bit. Hence an incompatibility. On Wed, Feb 3, 2010 at 7:53 PM, Xavi jara...@gmail.com mailto:jara...@gmail.com wrote: smu, set printer to ? set(24) // s/b , but set to LPT1 again Ok but it's also the default printer. Printer connected to port LPT1 in WoW and NTVDM DOS PC emulator under Windows. try .- FUNC MAIN() ? set(24) // Clipper is , Harbour is LPT1 set printer to (junk.txt) ? set(24) // junk.txt set printer to ? set(24) // s/b , but set to LPT1 again // set printer to LPT4 // set printer to set printer on ? Printed on default printer. RETURN -- Xavi El 03/02/2010 23:39, smu johnson escribió: FUNC MAIN() ? set(24) // Clipper is , Harbour is LPT1 set printer to (junk.txt) ? set(24) // junk.txt set printer to ? set(24) // s/b , but set to LPT1 again RETURN -- smu johnson smujohn...@gmail.com mailto:smujohn...@gmail.com mailto:smujohn...@gmail.com mailto:smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org mailto:Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- smu johnson smujohn...@gmail.com mailto:smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
To Viktor, El 03/02/2010 0:09, Viktor Szakáts escribió: for GPF at application startup caused by accessing TSD before HVM stack is initialized. It seems to work though it can be greatly simplified and of course the GPF in startup code and non HVM threads has to be fixed. That pretty much sums up what I didn't like about the implementation without even knowing the exact details (I'd have bet that MT mode had problems f.e.) That's great!. No Comments. :-) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugging c code
Hi April, HB_TRACEFM(), with my next commit. I'm waiting for Przemek and others are ready. ;) Is there a macro I can use to identify this sub-function? I could leave it in the code wrapped conditional code for debug only. Yes if you have a C99 compiler, just have to redefine the macro in your code .- #ifdef HB_TRACEFM # undef HB_TRACEFM # define HB_TRACEFM( x ) hb_fm_xInfoEx( #x, __FILE__, __LINE__, __func__ ); x #endif Best regards, Xavi El 01/02/2010 4:00, April White escribió: When my C level code does not release memory, the fm statistics reports this but gives the public function though in some cases the allocation occured in a sub-function. Is there a macro I can use to identify this sub-function? I could leave it in the code wrapped conditional code for debug only. April ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Extented FM Stats with new trace macro HB_TRFM.
Hi All, I've done extented FM Stats ST/MT for HB_FM_STATISTICS with new trace macro HB_TRFM(). This allows to show in hb_out.log the allocation of the pointer covert by the macro. HB_TRFM( pPtr = (char *)hb_xgrab( size ) ); or .- HB_TRFM( pObj = ( QTextDecoder* ) new QTextDecoder( hbqt_par_QTextCodec( 1 ) ) ); In order to have in hb_out.log for HB_FM_STATISTICS .- ... Total memory allocated: 234123 bytes (4176 block(s)) Warning, memory allocated but not released: 1020 bytes (2 block(s)) Block 1 0xd88970 (size 200) MYFUNCTION(256), 200F200F ... myfile.c:256 [ char *pPtr = (char *)hb_xgrab( size ) ] Block 2 0xe4a990 (size 200) QT_QTEXTDECODER(129), 200F200F ... qtcore.cpp:129 [ pObj = ( QTextDecoder* ) new QTextDecoder( hbqt_par_QTextCodec( 1 ) ) ] I think with this FM Stats do it more human-readable. The code is 100% compatible with existing. If not used HB_TRFM and HB_FM_STATISTICS you have the same until now. Macro have coverage until the first comma, for example in the expression .- pObj = ( QPoint* ) new QPoint( hb_parni( 1 ), hb_parni( 2 ) ) ; Use .- HB_TRFM( pObj = ( QPoint* ) new QPoint)( hb_parni( 1 ), hb_parni( 2 ) ) ; If you want I can commit it in SVN. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extented FM Stats with new trace macro HB_TRFM.
Hi Viktor, Anyhow its usefulness is limited as it requires code changes in thousands of places and these changes are quite intrusive, since they make code more difficult to read. Don't change the existing but new or 3-prt libraries can take advantage of this. Also, perhaps in the future, the macro can be extended to other checks and the code is not more difficult than HB_TRACE. I think that valgrind gives us this (and much more) already, so we should use it rather than compromising code readability. Unfortunately valgrind not exist in Windows and the alternatives are expensive. And we already have FM. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbQT - c++ stub - GC : Some food for thoughts
Pritpal,
I'm going to try extented FM Stats with something like this .-
HB_TRFM( char *pPtr = (char *)hb_xgrab( size ) );
or .-
HB_TRFM( pObj = ( QTextDecoder* ) new QTextDecoder( hbqt_par_QTextCodec( 1 ) )
);
In order to have in hb_out.log for HB_FM_STATISTICS .-
...
Total memory allocated: 234123 bytes (4176 block(s))
Warning, memory allocated but not released: 1020 bytes (2 block(s))
Block 1 0xd88970 (size 200) MYFUNCTION(256), 200F200F ...
myfile.c:256 [ char *pPtr = (char *)hb_xgrab( size ) ]
Block 2 0xe4a990 (size 200) QT_QTEXTDECODER(129), 200F200F ...
qtcore.cpp:129 [ pObj = ( QTextDecoder* ) new QTextDecoder(
hbqt_par_QTextCodec( 1 ) ) ]
I think with this FM Stats do it more human-readable, at least for me I find it
useful.
I hope it can help you.
Best regards,
--
Xavi
El 30/01/2010 3:12, Pritpal Bedi escribió:
Hello All,
What I did
Pulled code from hbMK2 and placed along hbIDE files
==
#include hbapi.h
#if defined( __cplusplus )
const char * __hbmk2_hbcppmm( void )
{
return HBCPPMM;
}
void * operator new[]( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
HB_TRACE( HB_TR_ALWAYS, ( void * operator new[]( size_t %i
), nSize ) );
return hb_xgrab( nSize );
}
void * operator new( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
void * pPtr = hb_xgrab( nSize );
HB_TRACE( HB_TR_ALWAYS, ( void * operator new( size_t %i )
%p, nSize, pPtr ) );
return pPtr;
}
void operator delete[]( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, (void operator delete[]( void * %p ), ptr
) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( void operator delete[]( void * %p
), ptr ) );
}
}
void operator delete[]( void * ptr, size_t )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, (void operator delete[]( void * %p, size_t
), ptr ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( void operator delete[]( void * %p,
size_t ), ptr ) );
}
}
void operator delete( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, (void operator delete( void * %p %i), ptr,
0 ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( void operator delete( void * %p
%i), ptr, 1 ) );
}
}
void operator delete( void * ptr, size_t nSize )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( void operator delete( void * %p, size_t
%i ), ptr, nSize ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( void operator delete( void * %p,
size_t ), ptr ) );
}
}
#endif
Included this file say, cppstub.cpp, in hbIDE.hbp.
Compiled hbIDE = hbmk2 hbide.hbp -l- -lpsapi -nohbcppmm
And under various sections of ideeditor.prg and HBQPlainTextEdit.cpp
I put tracelog. Mainly:
QT_G_FUNC( hbqt_gcRelease_HBQPlainTextEdit )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
Cargo;
if( p p-bNew )
{
if( p-ph p-pq )
{
const QMetaObject * m = ( ( QObject * ) p-ph )-metaObject();
if( ( QString ) m-className() != ( QString ) QObject )
{
HB_TRACE( HB_TR_ALWAYS, ( YES_rel_HBQPlainTextEdit
) );
delete ( ( HBQPlainTextEdit * ) p-ph );
HB_TRACE( HB_TR_ALWAYS, ( YES_rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB, p-ph, (void *)(p-pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
if ( p-ph )
{
HB_TRACE( HB_TR_ALWAYS, ( YES_rel_HBQPlainTextEdit ph=%p
-0, p-ph ) );
delete( p-ph );
HB_TRACE( HB_TR_ALWAYS, ( YES_rel_HBQPlainTextEdit ph=%p
-1, p-ph ) );
}
//p-ph = NULL;
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( NO__rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB, p-ph, (void *)(p-pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( DEL_rel_HBQPlainTextEdit
Object already deleted! ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( PTR_rel_HBQPlainTextEditObject
not created with - new ) );
p-ph = NULL;
}
}
void * hbqt_gcAllocate_HBQPlainTextEdit( void * pObj, bool bNew )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
hb_gcAllocate( sizeof( QGC_POINTER_HBQPlainTextEdit ), hbqt_gcFuncs() );
p-ph = pObj;
p-bNew = bNew;
p-func = hbqt_gcRelease_HBQPlainTextEdit;
if( bNew )
{
new( p-pq ) QPointer HBQPlainTextEdit
Re: [Harbour] hbwin.lib error
Hi,
Now everyone who use WIN_PRN class has to link his code
with PNG library even if it's unnecessary.
PNG library is used in win_BitMapDimensions, now is not used in WIN_PRN class
to print win_BMPs class.
Note that now it's a RAW implementation driver dependent and some drivers don't
need the original dimensions to work.
Unfortunately the PNG support is few used in win drivers.
win_BitMapDimensions works fine and can be nice changed win_BMP class with
attache sample prg.
Perhaps in future, we can change it to not RAW driver dependent and convert these formats into DIB plane but now, I don't know
how do it and if this is correct.
What do you think about?
Best regards,
Xavi
CREATE CLASS WIN_BMP
EXPORTED:
METHOD New()
METHOD LoadFile( cFileName, aDimXY )
METHOD Create()
METHOD Destroy()
METHOD IsSupported( oPrn, nError )
METHOD Draw( oPrn, aRectangle, nError )
VAR Type INIT 0 // Type BitMap: 1 == BM, 2 == JPEG, 3
== PNG
VAR DimXYINIT { 0, 0 } // Image Dimensions X Y pixels
VAR Rect INIT { 0, 0, 0, 0 } // Coordinates to print BitMap
// XDest,//
x-coord of destination upper-left corner
// YDest,//
y-coord of destination upper-left corner
// nDestWidth, // width
of destination rectangle
// nDestHeight, //
height of destination rectangle
// See WinApi StretchDIBits()
VAR BitMap INIT
VAR FileName INIT
ENDCLASS
METHOD New() CLASS WIN_BMP
RETURN Self
METHOD LoadFile( cFileName, aDimXY ) CLASS WIN_BMP
::FileName := cFileName
::Bitmap := win_LoadBitMapFile( ::FileName )
IF Empty( ::Bitmap )
::Type := 0
::DimXY := { 0, 0 }
ELSE
::Type := win_bitmapType( ::Bitmap )
IF ISARRAY( aDimXY )
::DimXY := aDimXY
ELSEIF ! win_BitMapDimensions( ::Bitmap, @::DimXY[1], @::DimXY[2] )
::DimXY := { 1, 1 } // Driver may use the original dimensions
ENDIF
ENDIF
RETURN ::Type != HB_WIN_BITMAP_UNKNOWN
METHOD Create() CLASS WIN_BMP // Compatibility function for Alaska Xbase++
RETURN Self
METHOD Destroy() CLASS WIN_BMP // Compatibility function for Alaska Xbase++
RETURN NIL
METHOD IsSupported( oPrn, nError ) CLASS WIN_BMP
RETURN ( nError := win_BitmapIsSupported( oPrn:hPrinterDc, ::Bitmap ) ) == 0
METHOD Draw( oPrn, aRectangle, nError ) CLASS WIN_BMP // Pass a WIN_PRN object
reference Rectangle array
IF ISARRAY( aRectangle )
::Rect := aRectangle
ENDIF
RETURN IIF( ::IsSupported( oPrn, @nError ), oPrn:DrawBitMap( Self ), .F. )
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13719] trunk/harbour
Hi Viktor, Thank you very much. It's wonderful include! Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compiling Postgres Lib in Windows
Bruno, Which package i need to install to get this files ? Download the sources .- http://www.postgresql.org/ftp/source Also, I think that zip archive has the includes .- http://www.postgresql.org/download/windows Advanced users can also download a _zip archive_ of the binaries, without the installer. -- Xavi El 26/01/2010 17:55, Bruno Luciani escribió: I don' t have postgres includes in my instalation Which package i need to install to get this files ? Postgres Standard Binary instalation do not have it Bruno ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Change win_BMP to allow printing compressed formats JPEGs, PNGs.
Hi, I've extended the class win_BMP to allow printing compressed formats JPEG and PNG if the driver allows it with a good result. Today many printers support these formats and not is the same, in network environments, send to printer 6MB in DIB plane that 90KB in JPEG. The code is 100% compatible with existing. Load supports JPEG and PNG files in addition to BMP and check the driver for printing. Any existing application by simply changing the file can exploit this advantage, of course, if your printer driver allows. If you want I can commit it in SVN. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Change win_BMP to allow printing compressed formats JPEGs, PNGs.
Hi Viktor, Ok, this afternoon I finish to tune some things and I do it. Best regards, Xavi El 24/01/2010 13:45, Viktor Szakáts escribió: Hi Xavi, That's great, I've actually started to fiddle with this exact same area in these moments. Pls commit. Brgds, Viktor On 2010 Jan 24, at 13:36, Xavi wrote: Hi, I've extended the class win_BMP to allow printing compressed formats JPEG and PNG if the driver allows it with a good result. Today many printers support these formats and not is the same, in network environments, send to printer 6MB in DIB plane that 90KB in JPEG. The code is 100% compatible with existing. Load supports JPEG and PNG files in addition to BMP and check the driver for printing. Any existing application by simply changing the file can exploit this advantage, of course, if your printer driver allows. If you want I can commit it in SVN. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13692] trunk/harbour
Hi Viktor, Do you know a way to determine .jpeg and .png image dimensions? ... I was going to respond before I see your changes that we need to use JPEG's and PNG's structs but... That's great!. I need to assimilate, it's sophisticated but look good. :) Thank you. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printing OEM_CHARSET win_prn()
Hi,
Still can not print graphics for example, chr(178).
Sorry, I can not help you, my system print correctly chr(178), U+2593 (0xB2):
Dark Shadow
Check it in the character map .-
http://windows.microsoft.com/pt-PT/windows-vista/Open-Character-Map
HTH
--
Xavi
El 18/01/2010 15:59, Itamar Lins escribió:
Hi!
Still can not print graphics for example, chr(178).
#include 'hbwin.ch'
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PTISO
Procedure Main ()
aPrn := GetPrinters()
HB_CDPSelect( PTISO )
HB_LANGSELECT( 'PT' )
If empty(aPrn)
MsgStop(Error)
return .f.
EndIf
oPrn := win_prn():New(GetDefaultPrinter())
oPrn :LandScape := .f.
oPrn :Copies:= 1
if !oPrn:Create()
MsgStop(error)
return nil
endif
if !oPrn:StartDoc(test)
MsgStop(Error)
return nil
EndIf
//oPrn:CharSet(ANSI_CHARSET)
//oPrn:Setfont('Lucida Console',,11) // oPrn:Setfont('Terminal',,12)
oPrn:CharSet(OEM_CHARSET)
oPrn:Setfont('Lucida Console',,11)
oPrn:SetPrc(1,0) //Is necessary, because if I omit not print first line.
oPrn:TextOut('Charset is: '+str(oPrn:Charset(),5),.t.)
oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)
For n := 1 to 255
oPrn:TextOut(chr(n),.t.)
if n == 60 .or. n == 120 .or. n == 180 .or. n == 240
oPrn:NewPage()
EndIf
Next
oPrn:EndDoc()
Best regards,
Itamar M. Lins Jr.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Printing OEM_CHARSET win_prn()
Itamar,
What is your compiler ?
My is MSVC express, and show small box, instead of characters. :-(
I think this has nothing to do with the C compiler and harbour.
Please check your system maybe not have the exact font name or oem version and
is associated with another.
Best regards.
--
Xavi
El 20/01/2010 17:09, Itamar Lins escribió:
What is your compiler ?
My is MSVC express, and show small box, instead of characters. :-(
Best regards,
Itamar M. Lins Jr.
Xavijara...@gmail.com escreveu na
mensagem news:4b571979.5060...@gmail.com...
Hi,
Still can not print graphics for example, chr(178).
Sorry, I can not help you, my system print correctly chr(178), U+2593
(0xB2): Dark Shadow
Check it in the character map .-
http://windows.microsoft.com/pt-PT/windows-vista/Open-Character-Map
HTH
--
Xavi
El 18/01/2010 15:59, Itamar Lins escribió:
Hi!
Still can not print graphics for example, chr(178).
#include 'hbwin.ch'
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PTISO
Procedure Main ()
aPrn := GetPrinters()
HB_CDPSelect( PTISO )
HB_LANGSELECT( 'PT' )
If empty(aPrn)
MsgStop(Error)
return .f.
EndIf
oPrn := win_prn():New(GetDefaultPrinter())
oPrn :LandScape := .f.
oPrn :Copies:= 1
if !oPrn:Create()
MsgStop(error)
return nil
endif
if !oPrn:StartDoc(test)
MsgStop(Error)
return nil
EndIf
//oPrn:CharSet(ANSI_CHARSET)
//oPrn:Setfont('Lucida Console',,11) // oPrn:Setfont('Terminal',,12)
oPrn:CharSet(OEM_CHARSET)
oPrn:Setfont('Lucida Console',,11)
oPrn:SetPrc(1,0) //Is necessary, because if I omit not print first line.
oPrn:TextOut('Charset is: '+str(oPrn:Charset(),5),.t.)
oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)
For n := 1 to 255
oPrn:TextOut(chr(n),.t.)
if n == 60 .or. n == 120 .or. n == 180 .or. n == 240
oPrn:NewPage()
EndIf
Next
oPrn:EndDoc()
Best regards,
Itamar M. Lins Jr.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Printing OEM_CHARSET win_prn()
Itamar,
... UNICODE setting, which is default for newer MSVC
targets, f.e. the Itamar is using.
??? Ok. No Comments. :)
Change .-
REQUEST HB_CODEPAGE_PTISO
...
HB_CDPSelect( PTISO )
With .-
REQUEST HB_CODEPAGE_PT850
...
HB_CDPSelect( PT850 )
Best regards.
--
Xavi
El 20/01/2010 17:09, Itamar Lins escribió:
What is your compiler ?
My is MSVC express, and show small box, instead of characters. :-(
Best regards,
Itamar M. Lins Jr.
Xavijara...@gmail.com escreveu na
mensagem news:4b571979.5060...@gmail.com...
Hi,
Still can not print graphics for example, chr(178).
Sorry, I can not help you, my system print correctly chr(178), U+2593
(0xB2): Dark Shadow
Check it in the character map .-
http://windows.microsoft.com/pt-PT/windows-vista/Open-Character-Map
HTH
--
Xavi
El 18/01/2010 15:59, Itamar Lins escribió:
Hi!
Still can not print graphics for example, chr(178).
#include 'hbwin.ch'
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PTISO
Procedure Main ()
aPrn := GetPrinters()
HB_CDPSelect( PTISO )
HB_LANGSELECT( 'PT' )
If empty(aPrn)
MsgStop(Error)
return .f.
EndIf
oPrn := win_prn():New(GetDefaultPrinter())
oPrn :LandScape := .f.
oPrn :Copies:= 1
if !oPrn:Create()
MsgStop(error)
return nil
endif
if !oPrn:StartDoc(test)
MsgStop(Error)
return nil
EndIf
//oPrn:CharSet(ANSI_CHARSET)
//oPrn:Setfont('Lucida Console',,11) // oPrn:Setfont('Terminal',,12)
oPrn:CharSet(OEM_CHARSET)
oPrn:Setfont('Lucida Console',,11)
oPrn:SetPrc(1,0) //Is necessary, because if I omit not print first line.
oPrn:TextOut('Charset is: '+str(oPrn:Charset(),5),.t.)
oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)
For n := 1 to 255
oPrn:TextOut(chr(n),.t.)
if n == 60 .or. n == 120 .or. n == 180 .or. n == 240
oPrn:NewPage()
EndIf
Next
oPrn:EndDoc()
Best regards,
Itamar M. Lins Jr.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WIN_DRAWBITMAP() with .png
Hi, I've never used tprn, but given a .png file you need to read it so that you have a DIB or BITMAP in memory. I think so. I read that some printer drivers are accepting png and jpeg directly, ... IMHO the correct direction to hbwin is allow printing JPGs and PNGs if takes it into memory. http://msdn.microsoft.com/en-us/library/dd145107%28VS.85%29.aspx What is the resolution on this? Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13563] trunk/harbour
Hi Viktor, So, in comparisons, should we always use _T(), while in assigments, this is not required? I think that also but for not enter in technical reasons about different compilers / machines. If you read a written code for ANSI / UNICODE you expect to see TCHAR's macros in literal constants if not, you should have an alarm justified or not. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13563] trunk/harbour
Hi Viktor, Okay, I'll mark them with TEXT(), is this alright? [ _T() is problematic as it needs yet another Windows header. But, TEXT() seems to work just as well for chars. ] Okay but they are very simple macros .- #ifdef UNICODE # define _TEXT(s) L##s #else # define _TEXT(s) s #endif #define _T(x) _TEXT(x) or .- #define HB_TEXT(x) TEXT(x) #define HB_T(x)TEXT(x) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13574] trunk/harbour
Thank you very much Przemek, + added support for __pragma(switchname ) in #if expressions, i.e.: #if __pragma( WARNINGLEVEL )= 3 #stdout Warnings set to level 3 or higher #endif #if !__pragma( z ) #stdout Shortcut optimization enabled #else #stdout Force complete boolean evaluation #endif #if __pragma( kj ) #stdout NO JUMP OPTIMIZATION #endif #if __pragma( km ) #stdout MACRO TEXT SUBSTITUTION DISABLED #endif #if __pragma( kh ) #stdout HARBOUR EXTENSIONS #endif I find it really useful because many codes may not work depending the type of compilation not only for Harbour extensions. For example the typical problems with shortcut disabled .- ... IF oGet != NIL .AND. oGet:TYPE == N ... Now we know how compile the code from code inside. -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13563] trunk/harbour
Hi Viktor,
! Fixed new warning in hb_tstrncat() (assigment in conditional).
I've now basically restored my original version taken from common lib.
Only one small observation as a comment.
Not is the same UNICODE NULL L'\0' that '\0', may be irrelevant because both
are zero.
Not is the same while( *pStr ) that while( *pStr != '\0' ).
IMHO maybe we need to define HB_TEXT and HB_T as TCHAR's _TEXT, _T macros. It's common practice in windows use _TEXT for user
messages and _T for internals like _T('\0'), I may be wrong and we just need to one macro but not only for WinCE.
Best regards,
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13549] trunk/harbour
Hi Przemek, + added new function hb_hashGetCItemPtr() which accepts ASCIIZ string as index. I don't know but may need HB_STACK_TLS_PRELOAD? Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13549] trunk/harbour
Hi Przemek, Thank to you, also it be good a cast in netiosrv.c line 494 .- conn-rpcFilter = ( PHB_SYMB ) hb_itemNew( pHash ); Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13558] trunk/harbour
Hi Viktor, MinGW, warning: unused parameter 'pSource' :) Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Study about return GCs generic.
Hi Przemek, Yes, it is. Anyhow accepting unknown pointer items is also wrong and I do not want to add to core code functions which are not usable for code which cleanly checks all pointer items. Yes I see it. Thank you for teach me to see. It can be done in few different ways, i.e. you can add public function which will operate on on different pointer items, or you can implement some casting or aliasing mechanism like the one I sent as example for HBQT few months ago. Looks that it creates problems for different developers so maybe in some spare time I'll try to add template code or some very basic HVM support for GC pointer item aliasing which should help in such situations. I read the example and no problem to wait for more. IMHO GC is one of the most important part of Harbour, I think it's better when more clear is the use and implementation. It can also facilitate the adaptation of 3rd party libraries that now use mostly plain pointers. Maybe I'll join it with OOP support for GC pointer items which is still on my TODO list. [ Yep! in C ... sorry, this excites me and brings back memories :) ] Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Study about return GCs generic.
Hi Przemek,
The ides of hb_itemGetPtrGC() is to _NOT_ make such things and return
_ONLY_ pointers which are exactly the requested type.
... Ok, I can assume so.
return ( HANDLE ) ( ph ? *ph : NULL );
But this assumes that it's always GC.
Perhaps we need an API function .-
BOOL hb_itemIsGC( PHB_ITEM pItem )
{
return (pItem HB_IS_POINTER( pItem ) pItem-item.asPointer.collect);
}
... will probably cause GPF or other bad side effects.
IMHO this is always difficult against misuse or indirection of pointers.
Maybe another kind of runtime type identification could help.
I don't know now.
Best regards,
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Study about return GCs generic.
Thank you very much Mindaugas,
I'm trying to mix both versions but when the address of the HB_GC_FUNCS is not
available I don't know how to do it.
Yes, thank you Przemek, I can do the same with .-
HANDLE wapi_par_HANDLE( int iParam )
{
PHB_ITEM pItem = hb_param( iParam, HB_IT_POINTER );
if( pItem pItem-item.asPointer.collect )
return ( HANDLE ) *(( void ** )pItem-item.asPointer.value);
return ( HANDLE ) ( pItem ? pItem-item.asPointer.value : NULL );
}
But I'm using internal HB_ITEM structure and also is wrong.
I use examples of hbwin because is in the repository and it's adapt well.
Try to imagine that wapi_CreateMutex() is in an external library.
How to do wapi_WaitForSingleObject() to accept the mutex?
Best regards,
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Study about return GCs generic.
Hi All,
IMHO the next changes in the functions hb_parptrGC and hb_itemGetPtrGC .-
void * hb_parptrGC( const HB_GC_FUNCS * pFuncs, int iParam )
{
HB_STACK_TLS_PRELOAD
HB_TRACE(HB_TR_DEBUG, (hb_parptrGC(%p,%d), pFuncs, iParam));
if( iParam = -1 iParam = hb_pcount() )
{
PHB_ITEM pItem = ( iParam == -1 ) ? hb_stackReturnItem() :
hb_stackItemFromBase( iParam );
if( HB_IS_BYREF( pItem ) )
pItem = hb_itemUnRef( pItem );
if( HB_IS_POINTER( pItem ) pItem-item.asPointer.collect )
{
if( pFuncs )
return (hb_gcFuncs( pItem-item.asPointer.value ) == pFuncs ?
pItem-item.asPointer.value : NULL);
else
return pItem-item.asPointer.value;
}
}
return NULL;
}
void * hb_itemGetPtrGC( PHB_ITEM pItem, const HB_GC_FUNCS * pFuncs )
{
HB_TRACE(HB_TR_DEBUG, (hb_itemGetPtrGC(%p,%p), pItem, pFuncs));
if( pItem HB_IS_POINTER( pItem ) pItem-item.asPointer.collect )
{
if( pFuncs )
return (hb_gcFuncs( pItem-item.asPointer.value ) == pFuncs ?
pItem-item.asPointer.value : NULL);
else
return pItem-item.asPointer.value;
}
else
return NULL;
}
Allows return generic GCs calling functions with pFuncs parameter to NULL.
As they are functions of our public API, IMO this facilitates development of libraries because may happen that the address of
function is unknown or static but we are interested in having the GC pointer.
For example .-
One possible implementation in wapi_par_HANDLE because the HANDLE can be pointer plane, GC or GC external (address of function
is unknown, static), could be .-
HANDLE wapi_par_HANDLE( int iParam )
{
void ** ph = ( void ** ) hb_parptrGC( NULL, iParam );
return (ph ? ( HANDLE ) *ph : ( HANDLE ) hb_parptr( iParam ));
}
What do you think about this?. Comments.
--
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Study about return GCs generic.
Hi Viktor, The case where pFunc is NULL seems to be covered already by existing pure hb_parptr() (and friend) functions. To me seems to not is covered because we need another function to know if it's collect or direct and take reference or address. return (ph ? ( HANDLE ) *ph : ( HANDLE ) ph ); Sorry, I don't know if I've explained well. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13494] trunk/harbour
Thank you for all Viktor. + contrib/hbwin/wapi_err.c * contrib/hbwin/hbwin.h * contrib/hbwin/hbwapi.h * contrib/hbwin/wapi_winbase.c I think wapi_err.c need include hbwapi.h for declare HB_EXPORT. And wapi_FormatMessage set lasterror, may be good call hbwapi_SetLastError. Best regards, -- Xavi El 07/01/2010 1:41, vszak...@users.sourceforge.net escribió: Revision: 13494 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13494view=rev Author: vszakats Date: 2010-01-07 00:41:10 + (Thu, 07 Jan 2010) Log Message: --- 2010-01-07 01:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/Makefile - contrib/hbwin/win_err.c + contrib/hbwin/wapi_err.c * contrib/hbwin/hbwin.h * contrib/hbwin/hbwapi.h * contrib/hbwin/wapi_winbase.c * contrib/hbwin/wapi_winuser.c * contrib/hbwin/wapi_winbase_mutex.c * Naming cleanup of recent change. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/wapi_winbase_mutex.c trunk/harbour/contrib/hbwin/wapi_winuser.c Added Paths: --- trunk/harbour/contrib/hbwin/wapi_err.c Removed Paths: - trunk/harbour/contrib/hbwin/win_err.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin wapi_GetLastError() issue.
Thank you Przemek, Please only try to remember that we cannot check each commit so try be careful when you update core code. I have this ever present. I love and work with Harbour. My interest in intervening in the project is to solve problems not create them. I'm sorry to I don't have full time for the project and not be much better with the letters. Best regards, -- Xavi El 07/01/2010 7:43, Przemysław Czerpak escribió: On Thu, 07 Jan 2010, Xavi wrote: Hi, I agree with that current code committed by Viktor is better but disagree with don't have acces to repository and update my code directly. I hope Viktor add you to developer list soon. Please only try to remember that we cannot check each commit so try be careful when you update core code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin wapi_GetLastError() issue.
Thank you very much Przemek,
Yes I know, if we start 32,536 threads .-
Procedure Main()
Local i, nETS := Seconds()
? 'Begin in', nETS, 'System Seconds.'
wapi_SetLastError( 0 )
? 'Main Process'
for i := 1 to 32536
hb_threadStart( @thFunc(), i )
? 'Thread', i
next
? 'End Time Elapsed', Seconds() - nETS, 'Seconds.'
Wait
return
Procedure thFunc( nThr )
wapi_SetLastError( nThr )
return
In my system generates a maximum of 1,140 pairs.
This means that a maximum of 1.140 pairs will be generated for all not in every
thread.
If we start 16 threads is generate 16 pairs and most multi-threaded programs using less than 16 threads that are alive until the
end. Sorry, I think it's not so bad _first solution where before we had a issue_.
I agree with that current code committed by Viktor is better but disagree with don't have acces to repository and update my code
directly.
best regards,
--
Xavi
El 06/01/2010 4:56, Przemysław Czerpak escribió:
On Wed, 06 Jan 2010, Xavi wrote:
Hi,
Only activating HB_TRACE() with any example of /test/mt and adding
wapi_SetLastError() you can see that this is not true.
Just store only a single ID/lasterror pairs by thread and these pairs
can be made easily accessible from another thread.
I think that C don't have the problems of spoken language such as English.
But sorry, I use my code resources made before and It's maybe the reason
for not having seen another solution for Harbour.
Please note that the code you sent creates an array of thread IDs.
Each unique thread ID ever given by the system to thread needs separate
entry. It's not guarantied that OS tries to use as small pool of thread
IDs as possible. Usually not because such condition needs additional
operation and creates potential problems for programmers so this is
rather range of numbers cyclically reused when free.
It means that in long running programs creating a lot of (even very short
life) threads this array is systematically growing up until it reach the
size of thread IDs range used by OS.
Then for each StoreLastError() operation this code makes covered by
mutex linear scan of this array to locate calling thread entry.
Because the array is big (probably few thousands of entries for each thread
which existed before and called at least once StoreLastError()) then it's
strongly time consuming operation which usually cost much more then the
whole operation setting it. It will kill the performance. Additionally
it strongly reduce scalability because this expensive and quite frequently
used in all WIN API functions which needs to store LastError scan operation
is covered by mutex.
Current code committed by Viktor use TLS on HVM stack what resolve such
problems. Anyhow such code used even without HVM should be fixed and it
can be easy done. Just simply call:
static DWORD s_dwTlsIndex = TLS_OUT_OF_INDEXES;
[...]
void StoreLastError( DWORD dwError )
{
if( s_dwTlsIndex == TLS_OUT_OF_INDEXES )
{
/* call it at least once before the 1-st thread is created to
avoid race condition and potential resource leak */
s_dwTlsIndex = TlsAlloc();
}
TlsSetValue( s_dwTlsIndex, ( LPVOID ) dwError );
}
DWORD RetrieveLastError( void )
{
return ( DWORD ) TlsGetValue( s_dwTlsIndex );
}
Please remember that size of TLS data is limited. In bigger programs
I suggest to make s_dwTlsIndex global variable initialized at startup
and then store inside pointer to dynamically allocated structure. In
such case your code will use only one TLS item just like Harbour for
HVM stack.
If it's necessary to access such structure also by other threads then
they should be additionally linked in some public list. This is also
done by HVM which keeps list of all HVM stacks.
HTH
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin wapi_GetLastError() issue.
Viktor,
Maybe I'm missing something, but I don't see why this needs
to be made that complicated. Windows already stores lasterror
in thread-local storage. Unless someone wants to use threads
created by non-Harbour means, storing lasterror for all
CPU threads inside every Harbour threads seems unnecessary.
Complicated is for me to understand why you say every Harbour threads and
repeat.
details, I don't understand why storing an array of thread
ID/lasterror pairs into _every_ Harbour thread is useful.
Only activating HB_TRACE() with any example of /test/mt and adding
wapi_SetLastError() you can see that this is not true.
Just store only a single ID/lasterror pairs by thread and these pairs can be
made easily accessible from another thread.
I think that C don't have the problems of spoken language such as English.
But sorry, I use my code resources made before and It's maybe the reason for
not having seen another solution for Harbour.
Code also uses a 'goto', which should IMO be replaced by
some other coding method.
This is new for me, goto is a C99 resource, I use with macros that generated
label/goto: something like this .-
#define CHKPTR( x ) if( !(x) ) do{ goto __func__##Error; }while( 0 )
#define FUN_ERRORgoto __func__##End; __func__##Error:
#define FUN_END __func__##End:
void Anyfunction( void )
{
void *pPtr;
CHKPTR( pPtr = malloc(16) );
...
...
...
FUN_ERROR
...
FUN_END
if( pPtr ) free( pPtr );
}
For me it's more easier to read, understand and maintain.
It stayed in the adapting to Harbour but I suppose that it's a new coding style
standard in Harbour.
* contrib/hbwin/wapi_winbase.c
+ Added hbwin_SetLastError(), hbwin_GetLastError()
low-level functions to save/get GetLastError() values.
This is required to preserve win lasterror value on .prg
level. The reason we need this is because TlsGetValue()
(called internally by Harbour core) is overwriting this
value. Thanks to Xavi for research.
Thanks to you and my sincere congratulations on your code, is better for
Harbour of course.
I don't have objection to change or replace my code with a code better, if not
I don't be released public but
_I am absolutely disagree because the changes are not made in the repository_.
I'd like to ask you to request R/W access on public
mailing list, it's not my personal project. It'd also be
good if other developers could also review this patch.
I've done and not just in this thread. I don't like the answer, no direct answer for to be accurate, but indirect understand and
it's obvious that my feelings are not the same as before. I sincerely hope to have contributed to solve the issue.
Sorry for the inconvenience and appreciate your patience.
Thank you.
Best regards.
--
Xavi
El 02/01/2010 18:28, Viktor Szakáts escribió:
Hi Xavi,
On 2010 Jan 2, at 17:47, Xavi wrote:
Viktor,
I have implemented the support in wapi_* for Windows API LastError.
I think that I should do the job of updating the repository, thank you very
much for doing before, I hope to consult you my doubts.
Does the ChangeLog file is automatically updated with the Message cangelog or
should we update it explicitly?
You need to modify it manually. Please read doc/howtosvn.txt.
I installed the TortoiseSVN and prepared the following update, I hope it's
correct.
Please, could you grant acces to ID jarabal in sourceforge.net
Message cangelog .-
* contrib/hbwin/hbwapi.h
+ added wapi_StoreLastError() declaration.
Since this is a low-level hbwin specific function
(or rather subsystem), please name it hbwin_StoreLastError()
and place implementation in new file win_err.c.
* contrib/hbwin/wapi_winbase.c
* moved wapi_SetLastError() and wapi_GetLastError()
to wapi_winbase_mutex.c
Please leave them in wapi_winbase.c. Each wrapper
should stay in the source which implements a given
set of functions, for WAPI_SET/GETLASTERROR() this is
wapi_winbase.c, since Set/GetLastError() Windows API
functions are declared in winbase.h. See:
http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx
* contrib/hbwin/wapi_winbase_mutex.c
+ Added support for Windows API LastError in ST/MT mode.
All functions wapi_* that can be used GetLastError()
should be stored the value using wapi_StoreLastError().
wapi_GetLastError() return the stored value by threads
before direct value of GetLastError().
Maybe I'm missing something, but I don't see why this needs
to be made that complicated. Windows already stores lasterror
in thread-local storage. Unless someone wants to use threads
created by non-Harbour means, storing lasterror for all
CPU threads inside every Harbour threads seems unnecessary.
Code also uses a 'goto', which should IMO be replaced by
some other coding method.
+ Added new PRG function .-
nSizeThrs := wapi_HB_WorkSpaceSLE( [nSizeIncThrs] )
By default wapi_StoreLastError() stores and increases every
[Harbour] To Admins: Harbour Windows APIs.
testwmtx.prg is an example of why not work wapi_GetLastError() .- --- testwmtx.prg STATIC s_hMutex PROCEDURE Main() LOCAL cAppName // It may be a random program name :) hb_FNameSplit( hb_ProgName(), NIL, @cAppName ) s_hMutex := wapi_CreateMutex( NIL, NIL, cAppName ) IF ! Empty( s_hMutex ) .AND. wapi_GetLastError() == 0 ? cAppName, = Hello World! OK. ELSE ? cAppName, = Application is running. Error, wapi_GetLastError() ENDIF WAIT RETURN --- In the second instance of the application fails because wapi_GetLastError() return 0. Compiling in MT mode, not define HB_USE_TLS and in Windows of course. _*WHAY*_ wapi_CreateMutex() call CreateMutex() Windows API function. CreateMutex() set the last error code to 183 ERROR_ALREADY_EXISTS (Is Ok the mutex already exit in the second instance). But wapi_CreateMutex() return with hb_ret* and this functions call hb_xgrab(). hb_xgrab() and MT mode call hb_mspace() and this call hb_stackAllocator(). hb_stackAllocator() call hb_stack_ready(). hb_stack_ready() call hb_tls_get() and hb_tls_get() is defined with TlsGetValue(). Windows API function TlsGetValue() in Header Winbase.h How to work with TlsGetValue() .- http://msdn.microsoft.com/en-us/library/ms686812%28VS.85%29.aspx The TlsGetValue function calls SetLastError to clear a thread's last error when it succeeds. TlsGetValue() set the last error code to 0 that is returned by wapi_GetLastError(). Not Ok, the Application is running. IMHO this is irrelevant, I don't like to limit Harbour internal to NOT WORK with Windows APIs. So I tried to update the repository with an implementation that supports in wapi_* for Windows API Last Error codes and plans to update (pre-alloc the memory) without success. Please, grant access to ID jarabal in sourceforge.net to update the repository. Thanks. :) -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about C macro HB_TRACE.
I answer myself .-
#ifdef _MAKET_H_
# ifdef _DEBUG
# define MK_ECHO_TRACE_HB_TR_DEBUG(x) do{ mk_ods x ; } while( 0 )
# else
# define MK_ECHO_TRACE_HB_TR_DEBUG(x)
# endif
# undef HB_TRACE
# define HB_TRACE(l, x) MK_ECHO_TRACE_##l(x)
#endif
Welcome 2010 :)
--
Xavi
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Question about C macro HB_TRACE.
I have this definition .- #ifndef _MAKET_H_ # ifdef _DEBUG # define mk_ods(fmt, ...) HB_TRACE(HB_TR_DEBUG, (fmt, ##__VA_ARGS__)) # else # define mk_ods(fmt, ...) # endif #endif mk_ods( Hello! ); How can I have the opposite? #ifdef _MAKET_H_ # undef HB_TRACE # ifndef _DEBUG # define HB_TRACE(HB_TR_DEBUG, (fmt, ...)) mk_ods(fmt, ##__VA_ARGS__) # else # define HB_TRACE(HB_TR_DEBUG, (fmt, ...)) # endif #endif HB_TRACE(HB_TR_DEBUG, (Hello!)); Sorry, it might be a nonsense but don't go out the errors. :'( Maket\wapi_winbase_mutex.c|91|error: ( may not appear in macro parameter list| Maket\wapi_winbase_mutex.c|91|warning: __VA_ARGS__ can only appear in the expansion of a C99 variadic macro| Maket\wapi_winbase_mutex.c||In function 'void wapi_SLE_Initialize(void*)':| Maket\wapi_winbase_mutex.c|105|error: 'HB_TRACE' was not declared in this scope| Maket\wapi_winbase_mutex.c|110|warning: left-hand operand of comma has no effect| Maket\wapi_winbase_mutex.c|110|warning: right-hand operand of comma has no effect| Maket\wapi_winbase_mutex.c|110|warning: right-hand operand of comma has no effect| Maket\wapi_winbase_mutex.c|111|error: expected ';' before '}' token| Maket\wapi_winbase_mutex.c|138|warning: 'static_int__hb_WAPI_Initialize_' defined but not used| ||=== Build finished: 3 errors, 5 warnings ===| I don't see, Can it be done easily? HB_TRACE is wonderful but in my case mk_ods control internal things of develop. TIA, -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HAPPY NEW YEAR !!!
Yep! HAPPY NEW YEAR to all. And hopefully fun!!! :) -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c
István,
.. and
inserts the necessary CR/LF for windbg
AFAIK only need '\n', if you like to jump the line and with DebugView, OutputDebugString() always introduce a line/entry into
the debugger displays for each call, ended or not with '\n'. If you insert '\n' in the middle of the string, this is divided
into two lines/entries but you can not put two calls into the same line/entry. Now with your change this always happens.
Please check with the DebugView .-
http://technet.microsoft.com/es-es/sysinternals/bb896647%28en-us%29.aspx
IMO should be user of function who choose to do. In my case I prefer as it was
before. :)
--
Xavi
El 27/12/2009 19:37, Bisz István escribió:
Hi Viktor,
This solution strips the trailing isspace characters from the debug info and
inserts the necessary CR/LF for windbg, not more.
Maybe we can define here a lot of similar solutions for the same thing.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2009. december 27. 19:27
To: Harbour Project Main Developer List.
Subject: [Harbour] Re: SF.net SVN: harbour-project:[13399]
trunk/harbour/src/common/hbtrace.c
Hi Istvan,
+ /*
+ * sizeof( buffer2 ) - 3 is room for CR/LF/NUL
+ */
if( proc )
- hb_snprintf( buffer2, sizeof( buffer2 ), %s:%d:%s() %s %s,
- file, line, proc, pszLevel, buffer1 );
+ n = hb_snprintf( buffer2, sizeof( buffer2 ) - 3, %s:%d:%s() %s
%s,
+ file, line, proc, pszLevel, buffer1 );
else
- hb_snprintf( buffer2, sizeof( buffer2 ), %s:%d: %s %s,
- file, line, pszLevel, buffer1 );
+ n = hb_snprintf( buffer2, sizeof( buffer2 ) - 3, %s:%d: %s %s,
+ file, line, pszLevel, buffer1 );
+ /*
+ * Normalize buffer2 with ending CR/LF/NUL
+ */
+ p = buffer2;
+ p += (n 0) ? sizeof( buffer2 ) - 3 : n;
+ while ( p buffer2 isspace( p[-1] ) )
+ {
+ *--p = '\0';
+ }
+ *p++ = '\r';
+ *p++ = '\n';
+ *p = '\0';
+
Maybe I'm missing something but isn't hb_snprintf() _always_
closing string with a zero? If not, we have serious security
problems in hundreds of places in Harbour.
If this is the case, we should rather fix hb_snprintf(),
than this one specific call of it.
Also, shouldn't \r \n simply added to printf mask string?
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c
El 27/12/2009 23:12, Bisz István escribió:
2. If fm.c is requested with -DHB_TR_LEVEL_DEBUG. The HB_TCHAR_CONVTO macro
calls indirectly HB_TRACE, generating in this way the mentioned stack
overflow. Fortunately debugged with windbg.
Sorry but ... What this issue has to do with this code?
...
/*
* Normalize buffer2 with ending CR/LF/NUL
*/
p = buffer2;
p += (n 0) ? sizeof( buffer2 ) - 3 : n;
while ( p buffer2isspace( p[-1] ) )
{
*--p = '\0';
}
*p++ = '\r';
*p++ = '\n';
*p = '\0';
...
If it is necessary we can generate here a flexible solution with and without
CR/LF, selectable by the existing HB_TR_WINOUT envvar.
Please, to which I can understand and sorry for my bad English.
Do you saying that windbg generate issue because the string does not end with
CR/LF.
TIA,
--
Xavi
El 28/12/2009 0:43, Bisz István escribió:
Hi Viktor,
I'd appreciate if you could describe it, as I don't have such
official debugger on my system, I used DbgView() for tests.
The windbg in a component of Microsoft Windows SDK for Windows 7 and .NET
Framework 3.5 SP1 / Debugging tools for Windows.
Dbgview is just a very useful viewer. I tested it and I cannot see any
differences comparing with the previous solution without CR/LF insertion.
If it is necessary we can generate here a flexible solution with and without
CR/LF, selectable by the existing HB_TR_WINOUT envvar.
If extra line ending (/r or /n or both) is required for windbg,
it's easy to add it to printf() calls, although I'm still not
sure why ending space trimming is required, or in which calls
does this exactly causes problems.
An any optimized solution is welcome, with the original solution the debug
messages are shown without line-feeds.
You're right, now it's clear. In this case the solution is to replace
HB_TCHAR_* macros with something native. I'll try to do it.
We need here a general solution taking into consideration the all possible
situations when HB_TRACE is called indirectly in HB_TRACE.
Best regards,
István
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13402] trunk/harbour
El 28/12/2009 2:04, vszak...@users.sourceforge.net escribió: * Adding \r\n for OutputDebugString() text to make WinDbg display look readable, this time by simply extending printf() mask. Thanks Viktor but I think adding just '\n' is sufficient and the code looks better. :) -- Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
