[Harbour] SF.net SVN: harbour-project:[14526] trunk/harbour

[vouchcac]

Revision: 14526
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14526&view=rev
Author:   vouchcac
Date: 2010-05-19 06:31:03 + (Wed, 19 May 2010)

Log Message:
---
2010-05-18 22:57 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/doc/en/class_hbqplaintextedit.txt
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
  * contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
  * contrib/hbqt/qtgui/THBQPlainTextEdit.prg
  * contrib/hbqt/qth/HBQPlainTextEdit.qth
  * contrib/hbide/ideedit.prg
  * contrib/hbide/ideeditor.prg
  * contrib/hbide/idesaveload.prg
  * contrib/hbide/ideshortcuts.prg

+ Implemented: proper hbIDEMap protocol. Now you can keep open
  "Source Thumbnail" dock and keep on clicking the tabs. Current  
  source map will be displayed inside. 
  
  hbIDEMap Features:

1. hbIDEMap carries highlighted code lines which are visible
   in main editing instance window. Navigaing the editor also
   changes highlighted area corresponding to main instance.
2. All keyboard mappings are active in the map also which implies
   that you can exercise copy operations which can be pasted 
   in the current code, a very useful feature.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/ideedit.prg
trunk/harbour/contrib/hbide/ideeditor.prg
trunk/harbour/contrib/hbide/idesaveload.prg
trunk/harbour/contrib/hbide/ideshortcuts.prg
trunk/harbour/contrib/hbqt/doc/en/class_hbqplaintextedit.txt
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h
trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg
trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth


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] SF.net SVN: harbour-project:[14525] trunk/harbour

[vouchcac]

Revision: 14525
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14525&view=rev
Author:   vouchcac
Date: 2010-05-19 02:09:52 + (Wed, 19 May 2010)

Log Message:
---
2010-05-18 18:55 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
  * contrib/hbide/hbide.prg
  * contrib/hbide/ideactions.prg
  * contrib/hbide/idedocks.prg
  * contrib/hbide/ideedit.prg
  * contrib/hbide/ideeditor.prg
  * contrib/hbide/ideobject.prg
! Fixed: selected text when viewed in a narrow window and 
  using horizontal scrollbars was showing incorrectly.

+ Implemented: current source's thumbnail view.
  It is presented in a right-hand docking widget which 
  can be activated via  menu. it is almost identical with
  current editor but with a significant difference that 
  it is loaded from the disk whenever the dock is brought to view.
  It contains smaller font and is entirely idependent 
  of main editing instance.

  It is just a quick commit. Refinement will follow.
  Please submit your suggestions.

  Re-compile hbQT alongwith hbIDE.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/hbide.prg
trunk/harbour/contrib/hbide/ideactions.prg
trunk/harbour/contrib/hbide/idedocks.prg
trunk/harbour/contrib/hbide/ideedit.prg
trunk/harbour/contrib/hbide/ideeditor.prg
trunk/harbour/contrib/hbide/ideobject.prg
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h


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] Re: SF.net SVN: harbour-project:[14524] trunk/harbour

[Pritpal Bedi]

WenSheng-2 wrote:
> 
>> Log Message:
>> ---
>> 2010-15-18 15:12 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
> Oh!My God! Year, 15 months :D
> 

I have looked at my fingers and surprisingly found they have gone broader.
Certainly I need doctors advise. Any good doctor in your vicinity ?


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14524-trunk-harbour-tp5072411p5072733.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Pritpal Bedi]

Antonio Maniero wrote:
> 
>> It persists.
>>
> 
> Not for me.
> 

Then it is a serious bug in hbIDE.

How do you activate hbIDE ?

Check if you can find "Projects Functions List" populated 
at startup after ( once ) tagging few projects ?

Show us hbIDE.ini responsible to load projects.


BTW, FYI
i just read these pages:
http://nickgravgaard.com/elastictabstops/
 
http://www.instantfundas.com/2009/10/minimap-plugin-for-visual-studio-jedit.html


First is based on Jave applet and so out of implementation.
I can only stretch myself what Qt provides in base API.

Second one I can implement, I think, but now sure. 
I will try.



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbIDE-http-hbide-vouch-info-Needed-your-Reviews-tp4925834p5072723.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
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:[14524] trunk/harbour

[WenSheng]

> Log Message:
> ---
> 2010-15-18 15:12 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
    Oh!My God! Year, 15 months :D
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Antonio Maniero]

>
>
>
> It persists.
>

Not for me.


>
> You need to re-tag only when you add a new project or
> there are heavy changes in your code. Recommened course is
> to re-tag every week to be on the safer side.
>
> Anyway, I admit that it needs a reworked approach.


Good.

BTW, FYI
i just read these pages:
http://nickgravgaard.com/elastictabstops/
 
http://www.instantfundas.com/2009/10/minimap-plugin-for-visual-studio-jedit.html


[]'s Maniero
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Pritpal Bedi]

Antonio Maniero wrote:
> 
>> Like some situations I already posted before and you put in your todo
>> list.
> I have a crash trying close a split editor but I can't reproduce it again.
> 

May be at those points you needed a re-build of hbQT.
This is some factor I could never control from inside hbIDE.



> When split editor vertically or horizontally pops a lot of problems with
> cursor, scrollbar and H/V rule marks.
> 

This is now another issue, not related with crash.



>> Sometimes works sometimes doesn't. I can say when (or why) doesn't work.
>> I
> will post here when I get a clue about it. Anyway HbIDE should persist
> tags
> in some way. Everytime I start HbIDE I need to retag. I never see this
> behavior in any code editor.
> 

It persists.

You need to re-tag only when you add a new project or 
there are heavy changes in your code. Recommened course is 
to re-tag every week to be on the safer side.

Anyway, I admit that it needs a reworked approach.

One such refinment I commintted some hours before.

-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbIDE-http-hbide-vouch-info-Needed-your-Reviews-tp4925834p5072465.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14519] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> Some more tests:
> 1)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()   (cursor changes position!)
> 
> 2)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()
> Down
> Down
> Down
> Down
> ::toggleStreamSelectionMode()  (cursor jumps a selects blocks)
> 
> 3)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()
> X (the whole block is filled by character X)
> 
> 4)
> ::toggleColumnSelectionMode()
> ::clearSelection() (cursor remains unvisible, text not editable. 
> Perhaps ::clearSelection shold stop selection process if it is started)
> 

1,2,4 fixed after r14524.

Some explanation for #3:

When cursor is in column selection anywhere, any character 
typed is "filling" it with it. It is speially helpful to clear a rect of 
any characters. I heavily use this feature and is a mainstay of 
xMate functionality.

This behavior cannot be set for program controlled selection because
the moment it is initiated selection mode is already set to normal.

If you move the cursor a column next you will not see this happen.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14519-trunk-harbour-tp5068769p5072437.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Antonio Maniero]

>
>
> >> Can you explain what constitute it to be unstable?
> >>
> > HbIDE crashs.
> >
>

> I do not experience it now, anybody else ? And can you describe
> circumstances, when ?
>
>
> Like some situations I already posted before and you put in your todo list.
I have a crash trying close a split editor but I can't reproduce it again.
When split editor vertically or horizontally pops a lot of problems with
cursor, scrollbar and H/V rule marks.


> You must not be following the exact sequence. It works. Please
> > re-read the ChangeLog entry. I will update online docs soon.
> >
> > So I suggest the sequence be:
> 1. right-click the function name
> 2. click on GOTO item on context menu
> Done. HbIDE gone to the function declaration. This is an intuitive and
> standard way to do this.
>
>
> I think you missed something.
> Here I explain again:
>
> 1. Click on "Projects Functions Lookup" docking widget.
> 2. Click on "Mark Projects" button.
> 3. In the popup component, check the blank checkboxes.
>These are the names of the projects visible in your "Projects" tree.
> 4. Click on "Re-Tags". Remember, this has to be done once.
> 5. Keep a watch on the window, after a little it will start
>   filling the list with function names. You will also visualize the
>   running number of functions added to the list.
> 6. After running numbers stops to increase, list will be populated
> entirely.
> 7. Close the window. You are ready to jump to the function.
> 8. To test: position the cursor on a function name which must be
>present in one of the projects you just re-tagged, right-click,
>select "Goto Function"...
>
> Report back if it worked.
>
>
> Sometimes works sometimes doesn't. I can say when (or why) doesn't work. I
will post here when I get a clue about it. Anyway HbIDE should persist tags
in some way. Everytime I start HbIDE I need to retag. I never see this
behavior in any code editor.

[]'s Maniero
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14524] trunk/harbour

[vouchcac]

Revision: 14524
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14524&view=rev
Author:   vouchcac
Date: 2010-05-18 22:15:12 + (Tue, 18 May 2010)

Log Message:
---
2010-15-18 15:12 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbide/ideedit.prg
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
! Fixed: more selections and cursor behavior.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/ideedit.prg
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp


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] Re: SF.net SVN: harbour-project:[14519] trunk/harbour

[Mindaugas Kavaliauskas]

On 2010.05.18 21:55, Pritpal Bedi wrote:

Some more tests:
1)
 ...


Once selection process is okayed, I will concentrate on the positioning
of cursor, which, in column selection mode specifically, is out or
order right now.

Please confirm that selection process, programatically and visually,
is correct in every respect.


Negative. See 2) and 4).

Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14523] trunk/harbour

[vouchcac]

Revision: 14523
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14523&view=rev
Author:   vouchcac
Date: 2010-05-18 21:35:15 + (Tue, 18 May 2010)

Log Message:
---
2010-15-18 14:30 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbide/hbide.prg
  * contrib/hbide/ideedit.prg
  * contrib/hbide/ideeditor.prg
  * contrib/hbide/idetags.prg
+ Implemented: Context-menu option "Goto Function" looks 
for the function/method in the current source first,
and if found, jumps to that, otherwise it rellies on 
tagging. It implies that functions in current source 
are always can be reached with "Goto Function" option
which operates on word under cursor.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/hbide.prg
trunk/harbour/contrib/hbide/ideedit.prg
trunk/harbour/contrib/hbide/ideeditor.prg
trunk/harbour/contrib/hbide/idetags.prg


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] SF.net SVN: harbour-project:[14522] trunk/harbour

[vouchcac]

Revision: 14522
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14522&view=rev
Author:   vouchcac
Date: 2010-05-18 20:02:35 + (Tue, 18 May 2010)

Log Message:
---
2010-15-18 13:00 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbide/ideprojmanager.prg
% Fixed: tab order in "Projects Properties" dialog.
  Thanks to Maniero for reporting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/ideprojmanager.prg


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] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Pritpal Bedi]

Antonio Maniero wrote:
> 
>> > Tab order on project properties is skipping some input boxes.
>>
>> Tab order is out of order.
> 

Fixed. r14520.



>> Can you explain what constitute it to be unstable?
>>
> HbIDE crashs.
> 

I do not experience it now, anybody else ? And can you describe 
circumstances, when ?


> You must not be following the exact sequence. It works. Please
> re-read the ChangeLog entry. I will update online docs soon.
>
> So I suggest the sequence be:
1. right-click the function name
2. click on GOTO item on context menu
Done. HbIDE gone to the function declaration. This is an intuitive and
standard way to do this.


I think you missed something.
Here I explain again:

1. Click on "Projects Functions Lookup" docking widget.
2. Click on "Mark Projects" button.
3. In the popup component, check the blank checkboxes.
These are the names of the projects visible in your "Projects" tree.
4. Click on "Re-Tags". Remember, this has to be done once.
5. Keep a watch on the window, after a little it will start 
   filling the list with function names. You will also visualize the 
   running number of functions added to the list.
6. After running numbers stops to increase, list will be populated entirely.
7. Close the window. You are ready to jump to the function.
8. To test: position the cursor on a function name which must be 
present in one of the projects you just re-tagged, right-click,
select "Goto Function"...

Report back if it worked.




>> No, I mean on Projects panel. It should allow open multiple files to
>> editor
> tabs. It's just a minor suggestion.
> 

I cannot achieve it because of some constraints.




>> I think you have examined it deeply, please forward the patch.
>>
>> Unfortunately I can't do that soon. It's a big job. For now I can suggest
> things and you decide what is your priority to do.
> 

:-(



> I will concentrate my suggestions in editor (not only widgets). I think
> this
> is the most important component of an IDE and it is a fundamental part for
> my choice about what IDE to use. However I won't post more suggestions for
> now. You have a lot of work to do yet.
> 

...

-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbIDE-http-hbide-vouch-info-Needed-your-Reviews-tp4925834p5071825.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] mingw 4.5.0 and upx

[Viktor Szakáts]

> fwiw,  I have found UPX to be a piece of crap for most applications.  Their 
> site shows that the idea was conceived and implemented during the days of 
> Pentium I computers, as all their CPU tests show that sort of historical 
> period.
> 
> You'd think that would be a good thing, but at the time 16 MB of ram a pretty 
> standard amount to have... which leads me to believe that in order to avoid 
> using RAM for UPX exes, they might have been uncompressed via the filesystem. 
>  They boast hardly any memory footprint, so I believe something tricky is 
> being done.
> 
> Problem is, on computers 10-15x that we have around the office, which have a 
> clock speed of probably 10 to 15 times that, the UPX exe's over a 100mbit 
> network sometimes take WAY longer to load... in the seconds, compared to 
> almost a fingersnap.  I'm not sure if my wild guess above is the cause for 
> it, but I tested this on about 5 computers at work to decide to stay away 
> from UPX, despite its nice reduction on our .EXE sizes...
> 
> I know this probably isn't relevant, but I thought I'd mention it anyhow, in 
> case someone else has noticed this.

That's interesting experience because the only reason 
I still use UPX is to shorten load times on networks, 
based on the theory that serving 2.5MB from the file 
server is quicker than serving 14MB.

Never made any load measurement though on a network.

The only noticeable effect on local machine is 
somewhat slower loading time due to lzma decompress 
phase. [ I use '-9 --lzma' mode. ]

[ The other good side effect is distribution size 
is smaller when using UPXed .exe since it uses lzma 
while for distro I still use .zip. The reason for 
.zip is that it's the best we have built in Harbour, 
and also the LCD. ]

Anyhow now I'm distributing without UPX and half of 
me is happy because dropping a tool from the toolchain 
is always nice, plus I find it more "honest" to distro 
vanilla executables, antivirus kits like it better, 
too.

So no huge loss, but it's good to know. I'd glady 
hear about more UPX experience, anyone?

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] mingw 4.5.0 and upx

[smu johnson]

fwiw,  I have found UPX to be a piece of crap for most applications.  Their
site shows that the idea was conceived and implemented during the days of
Pentium I computers, as all their CPU tests show that sort of historical
period.

You'd think that would be a good thing, but at the time 16 MB of ram a
pretty standard amount to have... which leads me to believe that in order to
avoid using RAM for UPX exes, they might have been uncompressed via the
filesystem.  They boast hardly any memory footprint, so I believe something
tricky is being done.

Problem is, on computers 10-15x that we have around the office, which have a
clock speed of probably 10 to 15 times that, the UPX exe's over a 100mbit
network sometimes take WAY longer to load... in the seconds, compared to
almost a fingersnap.  I'm not sure if my wild guess above is the cause for
it, but I tested this on about 5 computers at work to decide to stay away
from UPX, despite its nice reduction on our .EXE sizes...

I know this probably isn't relevant, but I thought I'd mention it anyhow, in
case someone else has noticed this.


On Tue, May 18, 2010 at 12:15 PM, Viktor Szakáts wrote:

> Hi All,
>
> FYI
>
> upx (even latest) won't work with mingw 4.5.0 built executables,
> due to 'CantPackException: TLS callbacks are not supported' error.
>
> In summary mingw added support for TLS callbacks in
> startup code, they also refused to make it optional,
> upx chokes on this and upx developer is not familiar
> with TLS callbacks, so it wasn't fixed to date.
>
> Here's the background:
>   http://old.nabble.com/Re:-TLS-Callback-Support-td27477588.html
>   http://comments.gmane.org/gmane.comp.gnu.mingw.devel/3550
>
> Viktor
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] mingw 4.5.0 and upx

[Viktor Szakáts]

Hi All,

FYI

upx (even latest) won't work with mingw 4.5.0 built executables, 
due to 'CantPackException: TLS callbacks are not supported' error.

In summary mingw added support for TLS callbacks in 
startup code, they also refused to make it optional, 
upx chokes on this and upx developer is not familiar 
with TLS callbacks, so it wasn't fixed to date.

Here's the background:
   http://old.nabble.com/Re:-TLS-Callback-Support-td27477588.html
   http://comments.gmane.org/gmane.comp.gnu.mingw.devel/3550

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14519] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> Some more tests:
> 1)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()   (cursor changes position!)
> 
> 2)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()
> Down
> Down
> Down
> Down
> ::toggleStreamSelectionMode()  (cursor jumps a selects blocks)
> 
> 3)
> ::toggleColumnSelectionMode()
> Down
> Down
> Right
> Right
> ::toggleColumnSelectionMode()
> X (the whole block is filled by character X)
> 
> 4)
> ::toggleColumnSelectionMode()
> ::clearSelection() (cursor remains unvisible, text not editable. 
> Perhaps ::clearSelection shold stop selection process if it is started)
> 

Once selection process is okayed, I will concentrate on the positioning 
of cursor, which, in column selection mode specifically, is out or 
order right now.

Please confirm that selection process, programatically and visually,
is correct in every respect.

Again thanks for tests, otherwise hbIDE would have been 
without these great features.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14519-trunk-harbour-tp5068769p5071536.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
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:[14519] trunk/harbour

[Mindaugas Kavaliauskas]

On 2010.05.18 21:12, Pritpal Bedi wrote:

This itiration has caused by not compiling hbQT.


Hmm... Some problem on my side, though recompiling hbqt did not helped. 
Recompiling all Harbour helped. I'm not sure that was the reason of 
this... Sorry.



Some more tests:
1)
   ::toggleColumnSelectionMode()
   Down
   Down
   Right
   Right
   ::toggleColumnSelectionMode()   (cursor changes position!)

2)
   ::toggleColumnSelectionMode()
   Down
   Down
   Right
   Right
   ::toggleColumnSelectionMode()
   Down
   Down
   Down
   Down
   ::toggleStreamSelectionMode()  (cursor jumps a selects blocks)

3)
   ::toggleColumnSelectionMode()
   Down
   Down
   Right
   Right
   ::toggleColumnSelectionMode()
   X (the whole block is filled by character X)

4)
   ::toggleColumnSelectionMode()
   ::clearSelection() (cursor remains unvisible, text not editable. 
Perhaps ::clearSelection shold stop selection process if it is started)



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Database close during index open failure

[Mindaugas Kavaliauskas]

Hi,



Not this time. We do not have any protection against closing WA
from any user code (i.e. key/for/filter/relation expressions or
from error handler) when it's used by RDD code :-(


Yes, I understand the problem. I've used to call DBCLOSEAREA() in my 
error block. This exploits the problem of WA protection against close.


Usually (in applications I've ever developed) the lack of WA protection 
is not a big problem. Do you think it's worth to add WA locking to Harbour?




Anyhow looking at your example I can see that one of them generates
internal error due to illegal value returned by error block.
This is also expected and Clipper compatible behavior.
Here is reduced example you can test also in Clipper:

PROC MAIN()
   ErrorBlock( {|| NIL } )
   BEGIN SEQUENCE
  ? array(0)[1]
   END SEQUENCE
RETURN


I've just used this error block behavior in make a small self contained 
sample. But the only the difference between test203 and test204 was open 
mode (shared vs exclusive), and this difference generates very different 
internal error, so, I've send both sample to indicate memory corruption 
problem.


Since array access is not recoverable error, block should not return at 
all, i.e., it should call BREAK() or __QUIT(). Am I right?



Thanks for your deep tests, regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14519] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> 1)
> ::toggleStreamSelectionMode()
> Down
> Down (do not select text - bad)
> 

It does.



> 2)
> ::toggleColumnSelectionMode()
> Down
> Left (do not select text - bad)
> 

It does.



> 3) Public methods in Keyboard Macros has names ::...SelectionMode(), but 
> you've wrote ::...Selection() in the text above, so it's completely not 
> clear that is right names.
> 

Sorry for inconvenience.
These are as ::...SelectionMode() in API calls.
When I wrote the message I could not recollect the exact call syntax.



> So, the only method that really works is ::clearSelection(). And I'm 
> getting a little tired of testing code that almost never do what is 
> expected. It seems that code is never tried to run and test by 
> developer. Code fixing is a kind of random movement with probability 0 
> to reach the goal.
> I'm also a little tired of explaining (again and again) the idea of 
> three selection modes what I've seen in MultiEdit, and what I'd like to
> use.
> 
> If I'll find more regressions than fixes in a few next tests, I'll drop 
> the idea of using hbide until I will not find time to develop it myself. 
> Though I'm not sure if it will ever happen.
> 

I am really sorry that you got bothered about number of iterations.
But this is the only way I can implement features beyond my current
knowledge.

This itiration has caused by not compiling hbQT.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14519-trunk-harbour-tp5068769p5071355.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14519] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> Hi.
> 
>>  + Finalized: all the three modes of selection programatically.
>>  ::toggleStreamSelection()No Key
>>  ::toggleColumnSelection()No Key
>>  ::toggleLineSelection()   == F11
>>  ::clearSelection()== Sh+F11
>>If a selection mode is initiated by above three methods,
>>it can only be exited by calling the same method again.
> 
> F11
> Down
> Down
> F11 does not stop selection, though text above says "can be exited" :(
> Down
> Down
> 
> Sh+F11 also do not stop selection, but unselects current selection. So, 
> I still do not know how can I implement ::stopSelection()
> 

Did you compile hbQT also ?


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14519-trunk-harbour-tp5068769p5071324.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
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:[14519] trunk/harbour

[Mindaugas Kavaliauskas]

On 2010.05.18 20:06, Mindaugas Kavaliauskas wrote:

Hi.


+ Finalized: all the three modes of selection programatically.
::toggleStreamSelection() No Key
::toggleColumnSelection() No Key
::toggleLineSelection() == F11
::clearSelection() == Sh+F11
If a selection mode is initiated by above three methods,
it can only be exited by calling the same method again.


F11
Down
Down
F11 does not stop selection, though text above says "can be exited" :(
Down
Down

Sh+F11 also do not stop selection, but unselects current selection. So,
I still do not know how can I implement ::stopSelection()


Also:

1)
::toggleStreamSelectionMode()
Down
Down (do not select text - bad)

2)
::toggleColumnSelectionMode()
Down
Left (do not select text - bad)

3) Public methods in Keyboard Macros has names ::...SelectionMode(), but 
you've wrote ::...Selection() in the text above, so it's completely not 
clear that is right names.


So, the only method that really works is ::clearSelection(). And I'm 
getting a little tired of testing code that almost never do what is 
expected. It seems that code is never tried to run and test by 
developer. Code fixing is a kind of random movement with probability 0 
to reach the goal.
I'm also a little tired of explaining (again and again) the idea of 
three selection modes what I've seen in MultiEdit, and what I'd like to use.


If I'll find more regressions than fixes in a few next tests, I'll drop 
the idea of using hbide until I will not find time to develop it myself. 
Though I'm not sure if it will ever happen.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Database close during index open failure

[Przemysław Czerpak]

On Tue, 18 May 2010, Mindaugas Kavaliauskas wrote:

Hi,

> >This is expected and documented few times on this list behavior.
> >Of course it's a bug but it cannot be well fixed without very serious
> >modifications in RDD code and all code (also 3-rd part one) which
> >access any RDD methods.
> >It's necessary to introduce sth like:
> >pArea = hb_rddLockCurrentArea();
> >[...] // any RDD methods
> >hb_rddFreeArea( pArea );
> >hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase
> >reference counter and hb_rddFreeArea() will decrease it.
> >non zero reference counter will delay releasing the pArea
> >structure until hb_rddFreeArea() will set it to 0.
> Thank You. I though it could something like:
> 2010-03-15 14:04 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>   * harbour/src/rdd/dbfcdx/dbfcdx1.c
> ! fixed bad copy and past typo which could cause internal error when
>   new index using existing order (subindex) was created without
> ADDITIVE
>   clause. Bug reported by Mindaugas - many thanks for the information.
> because we found this bug in a similar way in the same project.

Not this time. We do not have any protection against closing WA
from any user code (i.e. key/for/filter/relation expressions or
from error handler) when it's used by RDD code :-(
Anyhow looking at your example I can see that one of them generates
internal error due to illegal value returned by error block.
This is also expected and Clipper compatible behavior.
Here is reduced example you can test also in Clipper:

   PROC MAIN()
  ErrorBlock( {|| NIL } )
  BEGIN SEQUENCE
 ? array(0)[1]
  END SEQUENCE
   RETURN

best regards,
Przemek
___
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:[14519] trunk/harbour

[Mindaugas Kavaliauskas]

Hi.


 + Finalized: all the three modes of selection programatically.
 ::toggleStreamSelection()No Key
 ::toggleColumnSelection()No Key
 ::toggleLineSelection()   == F11
 ::clearSelection()== Sh+F11
   If a selection mode is initiated by above three methods,
   it can only be exited by calling the same method again.


F11
Down
Down
F11 does not stop selection, though text above says "can be exited" :(
Down
Down

Sh+F11 also do not stop selection, but unselects current selection. So, 
I still do not know how can I implement ::stopSelection()


Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14521] trunk/harbour

[druzus]

Revision: 14521
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14521&view=rev
Author:   druzus
Date: 2010-05-18 16:54:37 + (Tue, 18 May 2010)

Log Message:
---
2010-05-18 18:54 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbwin/win_svc.c
! fixed compilation with compilers which disable winsvc.h
  if WIN32_LEAN_AND_MEAN is set, i.e. POCC and XCC

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/win_svc.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:[14511] trunk/harbour

[Maurilio Longo]

Przemysław Czerpak wrote:
> modifications. I can compile the .PRG client and server example from
> xHarbour.com OLE server page. I only have to link at least one of
> components (server or client) statically because both linked dynamically
> with the same harbour.dll shares the same HVM so server fails inside
> hb_vmInit(). I can add protection against multiple HVM initialization
> anyhow using the same HVM for client and server code introduces
> interactions between them which do not use OLE API, i.e. they will
> use the same static variables.
> 
In OS/2 this is a .dll definition at compile time, that is, INITINSTANCE
clause inside .def file which tells the OS that the data segment has to be
private for each process that attaches to that .dll.

Hope this helps.

Maurilio.

PS. I'm sorry I haven't tested your serial routines under OS/2 yet, I simply
don't have any spare time right now, but they build fine, at least.

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Database close during index open failure

[Mindaugas Kavaliauskas]

Hi,


On 2010.05.18 15:00, Przemysław Czerpak wrote:

3 similar samples with different error, so, perhaps we have memory
corruption here.


This is expected and documented few times on this list behavior.
Of course it's a bug but it cannot be well fixed without very serious
modifications in RDD code and all code (also 3-rd part one) which
access any RDD methods.
It's necessary to introduce sth like:

pArea = hb_rddLockCurrentArea();
[...] // any RDD methods
hb_rddFreeArea( pArea );

hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase
reference counter and hb_rddFreeArea() will decrease it.
non zero reference counter will delay releasing the pArea
structure until hb_rddFreeArea() will set it to 0.


Thank You. I though it could something like:

2010-03-15 14:04 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/src/rdd/dbfcdx/dbfcdx1.c
! fixed bad copy and past typo which could cause internal error when
  new index using existing order (subindex) was created without 
ADDITIVE

  clause. Bug reported by Mindaugas - many thanks for the information.

because we found this bug in a similar way in the same project.


Regards,
Mindaugas
___
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:[14515] trunk/harbour

[Viktor Szakáts]

>> Before going further can you help define in 
>> normal words what is the description / distinction 
>> between -hbdyn and -hbdynvm modes?
> 
> -hbdyn creates DLL which is not linked with HVM.
> -hbdynvm creates DLL which is linked with HVM and
> other Harbour core libraries.
> 
>> When do we use which mode?
> 
> When we need or not HVM to be linked with final dynamic
> library so it depends on the code I'm linking.
> I can use -hbdyn to create DLL which does not have any
> references to Harbour core code.
> I can use -hbdyn and -lhbmaindllp to create DLL containing
> compiled .PRG modules (PCODE DLL) which can be dynamically
> loaded by static or dynamic Harbour application.
> I can use -hbdyn and -static to create self contain DLL
> which uses it's own private copy of HVM and Harbour RTL
> library which can be linked statically or loaded dynamically
> with/from any other applications, this application can use
> it's own HVM copy which will not interact with the one included
> in DLL in any way.
> I can use -hbdynvm and -shared to create PCODE DLL which can
> be linked statically or loaded dynamically by shared linked
> Harbour application and HVM code and structures are shared
> in such case.
> There are also many other situations when user may need -hbdyn
> or -hbdynvm.
> 
>> [ we now have .prg .dlls, "normal" .dlls, "VM" 
>> .dlls, but I'm starting to get confused, which 
>> means it's difficult to organize the internals. 
>> F.e. now I can introduce a new sub-switch inside 
>> -hbdyn mode for 'vm', or I could cleanup the modes 
>> into a flat list. ]
> 
> See above.
> Please also remember that dynamic shared libraries using HVM
> are initialized just like normal EXE files and when they contain
> their own HVM switches like -gt* should be enabled just for executable
> binaries. If they share HVM then you can also enable them and they will
> be ignored so you do not have to implement any special case for such
> situation.

Thank you, it more clear now. I'm quite busy now with 
other thing, but I'll make the hbmk2 changes ASAP.

>> Enabling specific features based on the mode is 
>> less of a problem.
>> 
>> Bonus: Do you have any hint how to use .def files 
>> with watcom compiler? Spent 1 hour on it to no avail, 
>> maybe it's too obvious or it was too late.
> 
> See my second message. WLINK seems to not accept .DEF files
> directly and uses a little bit different syntax. Only LINK
> can accept them and probably internally translates them to
> WLINK format. We can add translation from .DEF files to this
> format or we can simply include .DEF files directly using "@"
> command in WLINK .lnk file and user will have to use OpenWatcom
> compatible format for them.

Okay, I forgot for a moment watcom has a LINK command also.

So we have four options:
1. Let users mess with creating a watcom .def file
2. Let hbmk2 do the conversion to temp file and pass that to WLINK
3. To use LINK instead of WLINK for win/watcom targets.
4. To use LINK instead of WLINK for win/watcom targets 
   when .def file specified.

2. seems to be the best on the long run.

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:[14518] trunk/harbour

[francesco perillo]

Line blocks are the "yy" command in vi ? And the p/P for paste ? I use
it always (I don't know how to do other types of cut/paste in vi)

Francesco
___
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:[14515] trunk/harbour

[Przemysław Czerpak]

On Tue, 18 May 2010, Szak�ts Viktor wrote:

Hi,

> Before going further can you help define in 
> normal words what is the description / distinction 
> between -hbdyn and -hbdynvm modes?

-hbdyn creates DLL which is not linked with HVM.
-hbdynvm creates DLL which is linked with HVM and
other Harbour core libraries.

> When do we use which mode?

When we need or not HVM to be linked with final dynamic
library so it depends on the code I'm linking.
I can use -hbdyn to create DLL which does not have any
references to Harbour core code.
I can use -hbdyn and -lhbmaindllp to create DLL containing
compiled .PRG modules (PCODE DLL) which can be dynamically
loaded by static or dynamic Harbour application.
I can use -hbdyn and -static to create self contain DLL
which uses it's own private copy of HVM and Harbour RTL
library which can be linked statically or loaded dynamically
with/from any other applications, this application can use
it's own HVM copy which will not interact with the one included
in DLL in any way.
I can use -hbdynvm and -shared to create PCODE DLL which can
be linked statically or loaded dynamically by shared linked
Harbour application and HVM code and structures are shared
in such case.
There are also many other situations when user may need -hbdyn
or -hbdynvm.

> [ we now have .prg .dlls, "normal" .dlls, "VM" 
> .dlls, but I'm starting to get confused, which 
> means it's difficult to organize the internals. 
> F.e. now I can introduce a new sub-switch inside 
> -hbdyn mode for 'vm', or I could cleanup the modes 
> into a flat list. ]

See above.
Please also remember that dynamic shared libraries using HVM
are initialized just like normal EXE files and when they contain
their own HVM switches like -gt* should be enabled just for executable
binaries. If they share HVM then you can also enable them and they will
be ignored so you do not have to implement any special case for such
situation.

> Enabling specific features based on the mode is 
> less of a problem.
> 
> Bonus: Do you have any hint how to use .def files 
> with watcom compiler? Spent 1 hour on it to no avail, 
> maybe it's too obvious or it was too late.

See my second message. WLINK seems to not accept .DEF files
directly and uses a little bit different syntax. Only LINK
can accept them and probably internally translates them to
WLINK format. We can add translation from .DEF files to this
format or we can simply include .DEF files directly using "@"
command in WLINK .lnk file and user will have to use OpenWatcom
compatible format for them.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbide and character case

[Guy Roussin]

Hi Pritpal,


Now I need to know which action is causing.

When i click on the name of the source file, hbide
try to open the prg file but it can't because the
path is wrong ...

This is the reason I suggested to always use 
HB_FILEMATCH() when doing any comparison.


So if you lookup and change all filename 
comparisons (except where you compare types 
by looking at the extension only), you can 
safely remove all lowercasing and close the 
whole issue.


If you start it one-by-one per report, chances 
are good the code will never be right.
  

+1

I think lowercasing is need only when matching.
Never remember the result of lowercasing ...

Guy
___
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:[14515] trunk/harbour

[Viktor Szakáts]

>> 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>>; TODO: Couldn't find how to pass .def files to Open Watcom wlink.
>>Anybody with an experience here?

Just reinforced the question in another mail before 
reading this e-mail of yours.

> As I can see OW supports .def files only in 'link' command and
> wlink uses a little bit different format. It's necessary to use
> EXPORT command in .lnk file or include separate file with such
> definitions using @ command.
> Here are commands I used with Open Watcom:
> 
>   EXPORT DllGetClassObject   = '_dllgetclassobj...@12'  PRIVATE
>   EXPORT DllCanUnloadNow = '_dllcanunload...@0' PRIVATE
>   EXPORT DllRegisterServer   = '_dllregisterser...@0'
>   EXPORT DllUnregisterServer = '_dllunregisterser...@0'
>   EXPORT DllMain = '_dllm...@12'
> 
> We can add function which will translate .def files to this format
> or we can leave it for users and include them as separate in link
> script. But here we still have the problem that HBMK2 ignores
> commands like
>   -ldfl...@myolesrv.def
> Viktor for me it's a bug which should be fixed. Why you decided
> that HBMK2 should ignore compiler and linker command specified by
> user if they do not start with "-" character?
> In my opinion any  passed as -*flag= should be passed
> to corresponding Harbour/C compiler/linker and HBMK2 should not
> silently ignore only some of them. In some situations like above
> it's serious limitation.

Above should be solved differently. hbmk2 should handle 
such input files transparently. I don't see it huge problem, 
given that you're now trying to push the tool into its 
limits before having these features added natively to hbmk2.
Not a typical use-case.

So the key is '@'. Plus a different format. I vote to 
create an automatic converter to not put the burden on 
users to make the conversion manually, and make it 
easy to switch between compilers.

Anyhow I will add support for .def files (as-is) for now 
by passing them with '@' prefix. Later we can think about 
automatic conversion. It will require some ugly watcom 
specific hacks unfortunately. (why oh why did watcom opt 
for a non-standard solution. again.)

BTW, Sybase was bought by SAP. Along with Open Watcom 
and ADS.

> There is also yet another important problem with current OpenWatcom
> MS-Windows builds. Current harbour OW build time switches forces
> stack calling convention and not all Open Watcom libraries are compiled
> in this mode. It causes that it's not possible to use some extensions
> like OLE code due to unresolved external, i.e. try to link
> contrib/hbwin/tests/testax.prg
> If user wants to use OLE with Open Watcom builds then it has to
> recompile whole Harbour code with:
>   HB_USER_CFLAGS=-6r
> and then use -cflag=-6r HBMK2 parameter.
> Can we switch back OpenWatcom builds to its default calling convention?

Sure we can.

This means switching from -6s/-3s modes to -6r/-3r, 
is that right?

I can't remember why we switched to non-default though 
this the closest I could quickly find, seems resolved 
though:

2009-03-31 02:58 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
...
  * config/win/owatcom.cf
% Pentium Pro scheduling.
* Changed back to __cdecl calling convention from register based
  until we find a way to tweak HB_EXPORT to force __cdecl for
  .dll exported functions.
; TOFIX: Find out how to force __cdecl for HB_EXPORT functions in owatcom.
 Or, if this is no good solution for owatcom users, or not
 an option and performace is more important, we must rename
 owatcom Harbour .dlls to a distinct name: harbour[mt]-11-ow.dll.
 We should try to avoid that. [SOLVED]


Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Database close during index open failure

[Przemysław Czerpak]

On Tue, 18 May 2010, Mindaugas Kavaliauskas wrote:

Hi,

> 3 similar samples with different error, so, perhaps we have memory
> corruption here.

This is expected and documented few times on this list behavior.
Of course it's a bug but it cannot be well fixed without very serious
modifications in RDD code and all code (also 3-rd part one) which
access any RDD methods.
It's necessary to introduce sth like:

   pArea = hb_rddLockCurrentArea();
   [...] // any RDD methods
   hb_rddFreeArea( pArea );

hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase
reference counter and hb_rddFreeArea() will decrease it.
non zero reference counter will delay releasing the pArea
structure until hb_rddFreeArea() will set it to 0.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Cairo test.

[Mindaugas Kavaliauskas]

On 2010.05.18 14:04, Horodyski Marek (PZUZ) wrote:

To test this lib, I had to download from internet following dlls :
...
These dlls are incompatybile. Has anyone links to correct dlls or may
send on priv these dlls (on WinXP) ?


Some time ago I've compiled .dlll that does not depend on other non 
system dlls: www.dbtopas.lt/hrb/libcairo-2.dll


Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Database close during index open failure

[Mindaugas Kavaliauskas]

Hi,


3 similar samples with different error, so, perhaps we have memory 
corruption here.



Regards,
Mindaugas


C:\cawi32\sample\test>cat test203.prg
STATIC indexBlocks := {}
PROC MAIN()
  DBCREATE("test203.dbf", {{"F", "C", 1, 0}}, "DBFCDX", .T.)
  FERASE("tmp.cdx")
  AADD(indexBlocks, {|| FIELD->F})
  OrdCreate("tmp", "f", "IndexFunc()")
  DBCLOSEALL()
  indexBlocks := {}
BEGIN SEQUENCE WITH {|| err()}
  DbUseArea(.T., "DBFCDX", "test203",, .T., .F.)
  OrdListAdd("tmp.cdx")
END SEQUENCE
  DBCLOSEALL()
RETURN

FUNC err()
  DBCLOSEAREA()
RETURN NIL

FUNC IndexFunc()
RETURN EVAL(indexBlocks[1])


C:\cawi32\sample\test>hbrun test203.prg

Unrecoverable error 9104: hb_cdxIndexFree: index file still locked.
Called from DBCLOSEAREA(0)
Called from ERR(17) in pcode.hrb
Called from (b)MAIN(9) in pcode.hrb
Called from INDEXFUNC(21) in pcode.hrb
Called from ORDLISTADD(0)
Called from MAIN(11) in pcode.hrb
Called from HB_HRBRUN(0)
Called from _APPMAIN(0) in ../../../hbrun.prg

C:\cawi32\sample\test>cat test204.prg
STATIC indexBlocks := {}
PROC MAIN()
  DBCREATE("test204.dbf", {{"F", "C", 1, 0}}, "DBFCDX", .T.)
  FERASE("tmp.cdx")
  AADD(indexBlocks, {|| FIELD->F})
  OrdCreate("tmp", "f", "IndexFunc()")
  DBCLOSEALL()
  indexBlocks := {}
BEGIN SEQUENCE WITH {|| err()}
  DbUseArea(.T., "DBFCDX", "test204",, .F., .F.)
  OrdListAdd("tmp.cdx")
END SEQUENCE
  DBCLOSEALL()
RETURN

FUNC err()
  DBCLOSEAREA()
RETURN NIL

FUNC IndexFunc()
RETURN EVAL(indexBlocks[1])

C:\cawi32\sample\test>hbrun test204.prg

Unrecoverable error 9001: Error recovery failure
Called from INDEXFUNC(21) in pcode.hrb
Called from ORDLISTADD(0)
Called from MAIN(11) in pcode.hrb
Called from HB_HRBRUN(0)
Called from _APPMAIN(0) in ../../../hbrun.prg

C:\cawi32\sample\test>cat test205.prg
STATIC indexBlock

PROC MAIN()
  DBCREATE("test205.dbf", {{"F", "C", 1, 0}}, "DBFCDX", .T.)
  FERASE("tmp.cdx")
  indexBlock := {|| FIELD->F}
  OrdCreate("tmp", "block", "IndexFunc()")
  DBCLOSEALL()
  indexBlock := NIL
BEGIN SEQUENCE WITH {|| err()}
  DbUseArea(.T., "DBFCDX", "test205",, .F., .F.)
  OrdListAdd("tmp.cdx")
END SEQUENCE
  DBCLOSEALL()
RETURN

FUNC err()
  DBCLOSEAREA()
RETURN NIL

FUNC IndexFunc()
RETURN EVAL(indexBlock)

C:\cawi32\sample\test>hbrun test205.prg

Unrecoverable error 6005: Exception error:

Exception Code:C005
Exception Address:00545F65
EAX:0018F5D8  EBX:0006  ECX:002BDCBC  EDX:0028B95F
ESI:0001  EDI:0001  EBP:0018F618
CS:EIP:0023:00545F65  SS:ESP:002B:0018F5D0
DS:002B  ES:002B  FS:0053  GS:002B
Flags:00010202
CS:EIP: 8B 43 0C 50 E8 86 7E F0 FF 59 8B D0 8D 45 C0 8A
SS:ESP: 000C 0028B954 45444E49 4E554658 00292843  
     000


C stack:
EIP: EBP:   Frame: OldEBP, RetAddr, Params...
00545F65 0018F618   0018F67C 00546116 002BDCBC 0028B954 0001 
000C 0028B874 0020 0002 0001
00546116 0018F67C   0018FA9C 00573115 002BDCBC 0028B954 0028B70C 
0600 0028B874 0A00  
00573115 0018FA9C   0018FAC0 0057338D 0028B874 0028B784 0028B70C 
0018FAE4 434F4C42 004B 
0057338D 0018FAC0   0018FAE8 00574A5B 0028B70C 0028B85C 0600 
0028B70C 002BDE18 002BDCBC 0001 
00574A5B 0018FAE8   0018FC20 005780BE 0028B70C 0018FC0C 0028B127 
0001 002BDCBC 2E706D74 00786463 
005780BE 0018FC20   0018FC64 00540B3A 002BDCBC 0018FC30 00240564 
  0028B6AC  
00540B3A 0018FC64   0018FD6C 0043A6DF 0001 0028AFF4  
 0010 000A  0028B2A8
0043A6DF 0018FD6C   0018FD90 004404C8 0028B064 002BDB6C 0006 
 0028120C  000C
004404C8 0018FD90   0018FDA8 00464E8E 0024 0028AE1C 0028AFF4 
0001



Modules:
0x0040 0x00279000 c:\bin\hbrun.exe
0x7763 0x0018 C:\Windows\SysWOW64\ntdll.dll
0x7666 0x0010 C:\Windows\syswow64\kernel32.dll
0x7520 0x00046000 C:\Windows\syswow64\KERNELBASE.dll
0x7676 0x0010 C:\Windows\syswow64\USER32.DLL
0x75F6 0x0009 C:\Windows\syswow64\GDI32.dll
0x7696 0xA000 C:\Windows\syswow64\LPK.dll
0x75EC 0x0009D000 C:\Windows\syswow64\USP10.dll
0x76D4 0x000AC000 C:\Windows\syswow64\msvcrt.dll
0x76A4 0x000A C:\Windows\syswow64\ADVAPI32.dll
0x76C6 0x00019000 C:\Windows\SysWOW64\sechost.dll
0x76AE 0x000F C:\Windows\syswow64\RPCRT4.dll
0x751A 0x0006 C:\Windows\syswow64\SspiCli.dll
0x7519 0xC000 C:\Windows\syswow64\CRYPTBASE.dll
0x7600 0x00035000 C:\Windows\syswow64\WS2_32.DLL
0x75FF 0x6000 C:\Windows\syswow64\NSI.dll
0x76FD 0x0006 C:\Windows\system32\IMM32.DLL
0x7697 0x000CC000 C:\Windows\syswow64\MSCTF.dll
0x1000 0x00015000 c:\devel\Trmsv\trmglob.dll

Called from ORDLISTADD(0)
Called from MAIN(12) in pcode.hrb
Called from HB_HRBRUN(0)
Called from _APPMAIN(0) in ../../../hbrun.prg
___
Harbour mailing list

Re: [Harbour] SF.net SVN: harbour-project:[14515] trunk/harbour

[Viktor Szakáts]

Hi Przemek,

Before going further can you help define in 
normal words what is the description / distinction 
between -hbdyn and -hbdynvm modes?

When do we use which mode?

[ we now have .prg .dlls, "normal" .dlls, "VM" 
.dlls, but I'm starting to get confused, which 
means it's difficult to organize the internals. 
F.e. now I can introduce a new sub-switch inside 
-hbdyn mode for 'vm', or I could cleanup the modes 
into a flat list. ]

Enabling specific features based on the mode is 
less of a problem.

Bonus: Do you have any hint how to use .def files 
with watcom compiler? Spent 1 hour on it to no avail, 
maybe it's too obvious or it was too late.

Viktor

On 2010 May 18, at 10:25, Przemysław Czerpak wrote:

> On Tue, 18 May 2010, Przemysław Czerpak wrote:
> 
> Hi Viktor,
> 
>>> 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>>>  * utils/hbmk2/hbmk2.pt_BR.po
>>>  * utils/hbmk2/hbmk2.hu_HU.po
>>>  * utils/hbmk2/hbmk2.prg
>>>+ Added experimental -hbdynvm mode.
>>>+ Added support for .def input file in -hbdyn/-hbdynvm modes.
>> Thank you very much.
>> I'll check it tomorrow.
> 
> -hbdynvm enables static libraries (-nohblib-) and this works correctly.
> It does not enable linking temporary .c files with additional
> settings like requested and default driver, i.e. -gtgui is ignored.
> I also think that now -hbdyn (without 'vm' suffix) should not enable
> Harbour shared library by default when -shared switch is used. Separate
> switch -hbdynvm allows user to control it so and this is much better
> solution.
> So we need two additional modification:
> 1. enable the same temporary .c file used for .EXE files with
>   HVM startup settings with -gt* or -main=* switches when
>   dynamic library is created with -hbdynvm switch.
> 2. disable linking with harbour-*.dll when -hbdyn and -shared
>   are used
> The .def files with MinGW and MinGWCE builds work as expected.
> 
> Thank you very much.
> 
> 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] SF.net SVN: harbour-project:[14515] trunk/harbour

[Przemysław Czerpak]

On Tue, 18 May 2010, vszak...@users.sourceforge.net wrote:

Hi,

> 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> ; TODO: Couldn't find how to pass .def files to Open Watcom wlink.
> Anybody with an experience here?

As I can see OW supports .def files only in 'link' command and
wlink uses a little bit different format. It's necessary to use
EXPORT command in .lnk file or include separate file with such
definitions using @ command.
Here are commands I used with Open Watcom:

   EXPORT DllGetClassObject   = '_dllgetclassobj...@12'  PRIVATE
   EXPORT DllCanUnloadNow = '_dllcanunload...@0' PRIVATE
   EXPORT DllRegisterServer   = '_dllregisterser...@0'
   EXPORT DllUnregisterServer = '_dllunregisterser...@0'
   EXPORT DllMain = '_dllm...@12'

We can add function which will translate .def files to this format
or we can leave it for users and include them as separate in link
script. But here we still have the problem that HBMK2 ignores
commands like
   -ldfl...@myolesrv.def
Viktor for me it's a bug which should be fixed. Why you decided
that HBMK2 should ignore compiler and linker command specified by
user if they do not start with "-" character?
In my opinion any  passed as -*flag= should be passed
to corresponding Harbour/C compiler/linker and HBMK2 should not
silently ignore only some of them. In some situations like above
it's serious limitation.

There is also yet another important problem with current OpenWatcom
MS-Windows builds. Current harbour OW build time switches forces
stack calling convention and not all Open Watcom libraries are compiled
in this mode. It causes that it's not possible to use some extensions
like OLE code due to unresolved external, i.e. try to link
contrib/hbwin/tests/testax.prg
If user wants to use OLE with Open Watcom builds then it has to
recompile whole Harbour code with:
   HB_USER_CFLAGS=-6r
and then use -cflag=-6r HBMK2 parameter.
Can we switch back OpenWatcom builds to its default calling convention?

best regards,
Przemek
___
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:[14518] trunk/harbour

[Viktor Szakáts]

Hi,

>> I know I have to also paste it in column 1.
> 
> And this is the very inefficient part in stream block
> pasting which causes that they are not such flexible
> as line blocks when whole lines are copied. Just simply
> it forces additional horizontal cursor synchronization
> which is not necessary in line blocks.
> You may not use line blocks at all but believe me that
> for people who used real line blocks like in ME stream
> blocks is not serious alternative for whole line coping.

I'll look into myself why don't I miss this 
feature at all :) Even though I consider myself 
quite fast in editing.

To me pressing Home to go to col 1 is not a 
problem, and moving back to original col 
position is also something negligible in 
practice. Though for this to be true the 
editor is best to support moving past EOL. 
Something which is not supported by HBIDE and 
several other editors (f.e. vi, MSVS). It 
may help if cursor tries to jump back to 
original column, but for me it's rather 
confusing visually.

My only somewhat useful conclusion here is 
the you cannot just pick one feature and judge 
it by itself, you have to see the whole picture.

It's also about habits. And the "market share" 
of them.

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:[14518] trunk/harbour

[Przemysław Czerpak]

On Tue, 18 May 2010, Szak�ts Viktor wrote:

Hi,

> I know I have to also paste it in column 1.

And this is the very inefficient part in stream block
pasting which causes that they are not such flexible
as line blocks when whole lines are copied. Just simply
it forces additional horizontal cursor synchronization
which is not necessary in line blocks.
You may not use line blocks at all but believe me that
for people who used real line blocks like in ME stream
blocks is not serious alternative for whole line coping.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Cairo test.

[Horodyski Marek (PZUZ)]

To test this lib, I had to download from internet following dlls :

zlib1.dll
freetype6.dll
libfontconfig-1.dll

but now have I (my own translation) :

"unknown input point to procedure FT_GlyphSlot_Embolden in lib
freetype6.dll".

These dlls are incompatybile. Has anyone links to correct dlls or may
send on priv these dlls (on WinXP) ?

Regards,
Marek Horodyski


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: CHAN, was: Re: [Harbour] Vouch32 - Under Harbour Contrib

[Massimo Belgrano]

about CHANNEL Harbour idea

same contrib/3rd parties/addon will have a release cycle different from harbour
same contrib like hbct,hbmemio,hbnetio must be considered part of harbour
same contrib like all minigui version will have an external repository
all have in common hbmk2 as builder and build rules
IMO size of project , dependencies is important element to evaluate
wich kind project partecipate to channel
Internal contrib joined to harbour cycle of development
Internal contrib but Autonomy 3rd party
External 3rd

2010/5/18 Viktor Szakáts :
>
> At the end the idea is to have a flexible list of
> "addon" projects (we can call them "contribs" or
> "3rd parties" or whatever), where each addon can
> be easily added removed to/from the Harbour build
> process, and allowing the same to be done for
> distribution packages, and finally allowing such
> addon packages to be added/removed _after_
> installation on an end-user system.
>
> [ One another problem is to solve above "addon"
> system in a *nix environment. I haven't received
> any input about this so I'm still in the dark here. ]
>



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: CHAN, was: Re: [Harbour] Vouch32 - Under Harbour Contrib

[Viktor Szakáts]

Hi Martin,

On 2010 May 18, at 10:39, Martin Vogel wrote:

> Hi Pritpal, Viktor, all,
> 
> sorry for chiming in, but your discussion reminds me of an idea that, I hope 
> I remember that correctly, Phil Barnett had many years ago.
> 
> Why not follow the roads of TeX/LaTex, PERL et al. and create a comprehensive 
> harbour archive network, i.e. a package system for contribs?
> 
> I remember a discussion about splitting off "contrib" from core Harbour (also 
> many years ago), and people feared at that time that "contrib" would fall 
> behind in development, so the split was not done.
> 
> I think the situation has changed significantly since then. Harbour is stable 
> and mature now, a very good and solid base for library development. The focus 
> of development is now more and more in "contrib", correct me if I'm wrong.
> 
> "CHAN" could be integrated with hbIDE, for easy download, installation & 
> upgrade of libraries...
> 
> This way, core harbour would not be bloated and people might have an easier 
> way to start their own contribs, even if it was "only" platform-specific or 
> for a certain software environment...

I agree completely. Detachment of contribs from core is 
still an important issue to me, but putting the focus on 
the technical side of it, rather than dealing with the 
physical location of contrib sources. The latter is just 
a detail given we have proper infrastructure at hand.

The current goal is to move contribs to hbmk2 as their 
build tool. I've just added HB_BUILD_ADDONS which is 
another small step to this direction. With it, you can 
easily "integrate" additional "contribs" to the build 
process. .hbc files are in place.

One remaining task is invoking hbmk2 with .hbp files 
found in the contrib area, with proper 'clean' and 
'install' support.

Another remaining problem is dependency detection in hbmk2.

And another one is supporting special needs like 'moc' 
tool in HBQT. Honestly I have no idea how this will be 
solved yet.

At the end the idea is to have a flexible list of 
"addon" projects (we can call them "contribs" or 
"3rd parties" or whatever), where each addon can 
be easily added removed to/from the Harbour build 
process, and allowing the same to be done for 
distribution packages, and finally allowing such 
addon packages to be added/removed _after_ 
installation on an end-user system.

[ One another problem is to solve above "addon" 
system in a *nix environment. I haven't received 
any input about this so I'm still in the dark here. ]

BTW currently the package descriptor file is '.hbc'.

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:[14518] trunk/harbour

[Viktor Szakáts]

>> I'm copying lines by the thousands since long time
>> using stream method, and it causes no perceivable
>> overhead, so most probably I will not miss it in
>> my lifetime anymore. One less feature to worry about,
>> and this is always a good thing :)
> 
> I can only repeat myself: because you've never tried :)

I didn't miss it. Really. Plus it would really 
cut me off of most tools that I have around in 
case I'd cling onto this feature.

>> I absolutely agree, but can't this be made into
>> HBIDE in a simple way?
>> 
>> For example:
>> Shift+cursor: stream selection
>> Alt+cursor: block selection
>> Ctrl+cursor: line selection
> 
> For me the expected behaviour are:
>  Ctrl+Left,Right  word left, word right
>  Ctrl+Up Down scroll text up, down
> 
> Possiblity to not keep pressed Shift/Alt/Ctrl is very useful if large blocks 
> should be copied. Let's say I need to mark the whole text from the current 
> line to the end of file.
>   F7
>   Ctrl+PgDown
>   F7
> is very easy to press. Correct handling of Shift+Ctrl+PgDown helps here, but 
> not all functionality works if I need to keep some key pressed all the time.

Never found this a problem. Probably I'm too minimalistic.
Far Manager solves this by allowing all normal navigations 
while keeping Shift or Alt pressed.

Editor is probably like a shoe or coat, everyone has something 
else which fits perfectly. [ I've yet to find this one on OS X 
and Linux. ]

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

CHAN, was: Re: [Harbour] Vouch32 - Under Harbour Contrib

[Martin Vogel]

Hi Pritpal, Viktor, all,

sorry for chiming in, but your discussion reminds me of an idea that, I 
hope I remember that correctly, Phil Barnett had many years ago.


Why not follow the roads of TeX/LaTex, PERL et al. and create a 
comprehensive harbour archive network, i.e. a package system for contribs?


I remember a discussion about splitting off "contrib" from core Harbour 
(also many years ago), and people feared at that time that "contrib" 
would fall behind in development, so the split was not done.


I think the situation has changed significantly since then. Harbour is 
stable and mature now, a very good and solid base for library 
development. The focus of development is now more and more in "contrib", 
correct me if I'm wrong.


"CHAN" could be integrated with hbIDE, for easy download, installation & 
upgrade of libraries...


This way, core harbour would not be bloated and people might have an 
easier way to start their own contribs, even if it was "only" 
platform-specific or for a certain software environment...


Just my 2 cents,
Martin
--

On 17.05.2010 17:52, Viktor Szakáts wrote:

Hi Pritpal,


Though it compiles fine with current Harbour and possibly with -DUNICODE
also but still it may require an overhaul. The style is sephagatti as it
was started after my first encounter with xHarbour in 2002 and
when Augusto Infante and Andy Wos committed What32 library.
So it is not Harbour standards strictly.

The library is heavily based on What32 which I have as unified with
this library with Wvn_* name space. As hbwin.lib has evoled to a
reasonable extent, many of the functions will have duplication
but because namespace is different, will not cause any harm.

It also uses C Structures so again it does not adhere to Harbour's
philosophy.

The areas of particular interest to users will be PageScript compatible
functions and PrintPreview mechanism which can be exploited
with gtwin also though these are more suitable for gtwvt and gtwvg.
Though there are a lot other convinient functions but probably
I think all can be done more or less with current Harbour.

Few components I will have to pull out like Graphics and Charts
because the code was given to me by Augusto Infante and later
revised by Andy Wos and I do not know if I am permitted to publish
that as open source.

Augusto or Andy, if you are reading this mail, please allow to do so.

Also I wil pull-out CT3 compatible COM_* components as these are now
available with Harbour anyway and also due to fact that I had contributed
this library to xhb.com and my professional ethics do not permit so.

Today, 17 May 2010, I have decided to put it under Harbour contribs.
But I want to retain vouch32 folder name in harbour/contrib/vouch32.
This is the only recognistion I need plus your willingness to polish
the code. I would have certainly be happy to polish it but due to
heavy involvement with hbQt+ direction, I cannot spare time onto that.

If group is willing I can start the process under harbour/contrib/vouch32.


Thanks a lot for your offer.

Unfortunately I'm not very positive about the inclusion in
contrib, having went through all the trouble with WHAT32
in the past.

Even with small Windows code, there is A LOT of work to make
it compile (see service and MAPI support for two examples)
and to make it work on all our supported environments and to
level it to Harbour standards. It also has to be maintained
by someone, otherwise it can easily become a build stopper
(as was with WHAT32 and as is sometimes with GTWVG).

Also Harbour contrib is already getting overbloated (both
in terms of size and build-time), so for VOUCH32, I'd like
to suggest to create hbmk2 make files for it and host it
in another repository. I'm sure it will be much easier and
most probably more convenient for everyone.

I'd suggest to remove '32' from the name. In case of Harbour,
I went to great pain to remove any "bitness" information
from all the files, suggesting the portable nature of our
(Windows) code.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour



--
Martin Vogel
Neckarstraße 28
69469 Weinheim
Tel.: 06201/182410
Fax: 06201/182410
Mobil: 0171/4505008
Email: m-vo...@gmx.net
___
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:[14518] trunk/harbour

[Mindaugas Kavaliauskas]

On 2010.05.18 11:12, Viktor Szakáts wrote:

That's because you've never tried line selection mode. After you'll try it, 
you'll miss it. I promise you :)


I'm copying lines by the thousands since long time
using stream method, and it causes no perceivable
overhead, so most probably I will not miss it in
my lifetime anymore. One less feature to worry about,
and this is always a good thing :)


I can only repeat myself: because you've never tried :)



I absolutely agree, but can't this be made into
HBIDE in a simple way?

For example:
Shift+cursor: stream selection
Alt+cursor: block selection
Ctrl+cursor: line selection


For me the expected behaviour are:
  Ctrl+Left,Right  word left, word right
  Ctrl+Up Down scroll text up, down

Possiblity to not keep pressed Shift/Alt/Ctrl is very useful if large 
blocks should be copied. Let's say I need to mark the whole text from 
the current line to the end of file.

   F7
   Ctrl+PgDown
   F7
is very easy to press. Correct handling of Shift+Ctrl+PgDown helps here, 
but not all functionality works if I need to keep some key pressed all 
the time.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Vouch32 - Under Harbour Contrib

[Saulius Zrelskis]

Hi,

> I only haven't
> added support for nBufferIn and nBufferOut because only MS-Windows
> support it and it's not clear how it effect low level serial driver.
> Anyhow I'll think about adding it in the future.
A process reinitializes a communications resource by using the
SetupComm function, which performs the following tasks:
* Terminates pending read and write operations, even if they
   have not been completed.
* Discards unread characters and frees the internal output and
  input buffers of the driver associated with the specified resource.
* Reallocates the internal output and input buffers.

> BTW does anyone know the default size of serial IO buffers in
>    MS-Windows?
IMO there is no default sizes, only max sizes if imposed by
the serial provider.
GetCommProperties function fills in a COMMPROP structure
values like dwMaxTxQueue and dwMaxRxQueue.

Best regards,
Saulius
___
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:[14515] trunk/harbour

[Przemysław Czerpak]

On Tue, 18 May 2010, Przemysław Czerpak wrote:

Hi Viktor,

> > 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> >   * utils/hbmk2/hbmk2.pt_BR.po
> >   * utils/hbmk2/hbmk2.hu_HU.po
> >   * utils/hbmk2/hbmk2.prg
> > + Added experimental -hbdynvm mode.
> > + Added support for .def input file in -hbdyn/-hbdynvm modes.
> Thank you very much.
> I'll check it tomorrow.

-hbdynvm enables static libraries (-nohblib-) and this works correctly.
It does not enable linking temporary .c files with additional
settings like requested and default driver, i.e. -gtgui is ignored.
I also think that now -hbdyn (without 'vm' suffix) should not enable
Harbour shared library by default when -shared switch is used. Separate
switch -hbdynvm allows user to control it so and this is much better
solution.
So we need two additional modification:
1. enable the same temporary .c file used for .EXE files with
   HVM startup settings with -gt* or -main=* switches when
   dynamic library is created with -hbdynvm switch.
2. disable linking with harbour-*.dll when -hbdyn and -shared
   are used
The .def files with MinGW and MinGWCE builds work as expected.

Thank you very much.

best regards,
Przemek
___
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:[14518] trunk/harbour

[Viktor Szakáts]

>> So, I never in the last 15 years missed this feature.
>> Stream handles the matter just fine:
>>   Home, Shift+Up/Down,, PgUp/PgDn/Up/Down
>>   to proper place,, bingo.
> 
> That's because you've never tried line selection mode. After you'll try it, 
> you'll miss it. I promise you :)

I'm copying lines by the thousands since long time 
using stream method, and it causes no perceivable 
overhead, so most probably I will not miss it in 
my lifetime anymore. One less feature to worry about, 
and this is always a good thing :)

>> Seems much simpler than selecting between 3 different
>> selection modes, keeping them in mind, mousing in
>> between and pressing out of reach keys like F11, let
>> alone Shift+F11.
> 
> You do not need to keep them in mind and you do not need use mouse. Usually I 
> can keep mouse upside down. That's only the problem of current hbide 
> behaviour. In current hbide code exists application state "active selection 
> mode", but it should be implemented a different way: a different keys should 
> start a different types of selections, and no "active selection mode" status 
> at all. That's why I'm asking about ::startColumnSelection() instead of 
> current ::toggleColumnSelectionMode().

I absolutely agree, but can't this be made into 
HBIDE in a simple way?

For example:

Shift+cursor: stream selection
Alt+cursor: block selection
Ctrl+cursor: line selection

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:[14518] trunk/harbour

[Mindaugas Kavaliauskas]

Viktor,



So, I never in the last 15 years missed this feature.
Stream handles the matter just fine:
   Home, Shift+Up/Down,, PgUp/PgDn/Up/Down
   to proper place,, bingo.


That's because you've never tried line selection mode. After you'll try 
it, you'll miss it. I promise you :)




Seems much simpler than selecting between 3 different
selection modes, keeping them in mind, mousing in
between and pressing out of reach keys like F11, let
alone Shift+F11.


You do not need to keep them in mind and you do not need use mouse. 
Usually I can keep mouse upside down. That's only the problem of current 
hbide behaviour. In current hbide code exists application state "active 
selection mode", but it should be implemented a different way: a 
different keys should start a different types of selections, and no 
"active selection mode" status at all. That's why I'm asking about 
::startColumnSelection() instead of current ::toggleColumnSelectionMode().



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour ecosystem

[Alex Strickland]

Viktor Szakáts wrote:


In this case I tend to think for Harbour it's enough to
create a page with all the links pointing to different projects,
but more importantly (as discussed previously) to ensure that
these 3rd party projects can be compiled, linked and used in
more or less common way, f.e. by providing .hbp files to build
the project and .hbc file to link the project.


This subject has come up many times over the years, and the status quo remains, 
mainly I think because there are always good arguments pro and con. But you have 
made an excellent point here, hbmk2 can really simplify creation and usage of 
3rd party projects.


Regards
Alex
___
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:[14518] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,


On 2010.05.18 10:11, Viktor Szakáts wrote:

What is the reason you want to handle "line"
selection separately from stream selection?

Line selection looks like a stream which ends
and begins at column zero.

Could be much simpler with two modes: stream and block.


Yes, line mode is a similar to stream mode, but you do not have to move 
to beginning of line (that's simple, just press [Home]) and latter you 
do not have to move back to the same position (that's a lot of cursor 
movements). I find this very useful. The examples of typical usage are:

1) duplicate line
::startLineMarking()
::stopMarking()
::copyBlock()
it's 3 key strokes (two of them are the same key, so, it's very fast): 
F7 F7 F8


Try to compare to standard Windows behaviour without persistent blocks:
Home
Shift+Down
Ctrl+C
Up
Ctrl+V
Left
Left
Left
(and more 30 times Left to position cursor to the same column)

2) swap to lines
::startLineMarking()
::stopMarking()
Up
::moveBlock()
keystokes
 F7 F7 Up Shift+F8


3) almost any copy-paste code is duplicated using line block, because 
you do not need to care about cursor position. Usually you need to 
change some characters in the middle of line (but not in the first 
column), so you save a lot of cursor positioning movements using line block.



I thing, those, who is happy with two selection modes, can do not bind 
additional key to ::toggleLineSelectionMode() and have only two of them.



Regards,
Mindaugas
___
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:[14518] trunk/harbour

[Viktor Szakáts]

>> What is the reason you want to handle "line" 
>> selection separately from stream selection?
>> Line selection looks like a stream which ends 
>> and begins at column zero.
>> Could be much simpler with two modes: stream and block.
> 
> It's not the same.
> When you paste line selected block then you do not have to
> keep cursor at column 0 to insert it as whole lines. Stream
> block has such condition otherwise pasted text will start
> at current cursor column.
> In general line blocks allow to select and paste whole
> lines without respecting the cursor column position.
> It's really useful feature.

I know I have to also paste it in column 1.

Which is where you are when you made the selection, 
so requires no extra attention in most case, if it 
does, a Home button will get it right in a natural 
way.

So, I never in the last 15 years missed this feature. 
Stream handles the matter just fine:
  Home, Shift+Up/Down, , PgUp/PgDn/Up/Down 
  to proper place, , bingo.

Seems much simpler than selecting between 3 different 
selection modes, keeping them in mind, mousing in 
between and pressing out of reach keys like F11, let 
alone Shift+F11.

Simplicity is key, and I highly miss that in this 
editor.

BTW I have to think very hard to find an editor 
with separate line selection feature, I couldn't 
even tell one, except maybe some CUI based ones, 
like MC's built in editor, where it's the only 
(or default?) option.

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:[14518] trunk/harbour

[Przemysław Czerpak]

On Tue, 18 May 2010, Szak�ts Viktor wrote:

Hi,

> What is the reason you want to handle "line" 
> selection separately from stream selection?
> Line selection looks like a stream which ends 
> and begins at column zero.
> Could be much simpler with two modes: stream and block.

It's not the same.
When you paste line selected block then you do not have to
keep cursor at column 0 to insert it as whole lines. Stream
block has such condition otherwise pasted text will start
at current cursor column.
In general line blocks allow to select and paste whole
lines without respecting the cursor column position.
It's really useful feature.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14520] trunk/harbour

[vszakats]

Revision: 14520
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14520&view=rev
Author:   vszakats
Date: 2010-05-18 07:20:20 + (Tue, 18 May 2010)

Log Message:
---
2010-05-18 09:19 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/memvarhb.prg
* HB_MVSAVE(): reset to be a FUNCTION to avoid the "volatile"
  return value and better imitate __MVSAVE() behavior.
% HB_MVSAVE(): deleted unnecessary UPPER().
- Deleted TODO.

  * ChangeLog
* Marked TODOs as done. (Thanks Przemek)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rtl/memvarhb.prg


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:[14518] trunk/harbour

[Viktor Szakáts]

> 2010-15-17 19:05 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
>  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
>  * contrib/hbqt/hbqt_hbqplaintextedit.h
>  * contrib/hbide/ideedit.prg
>  * contrib/hbide/ideeditor.prg
>  * contrib/hbide/ideshortcuts.prg
>+ Prepared to handle three modes of selections programatically.
>  F11 Line Selection is broken currently.

What is the reason you want to handle "line" 
selection separately from stream selection?

Line selection looks like a stream which ends 
and begins at column zero.

Could be much simpler with two modes: stream and block.

Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14519] trunk/harbour

[vouchcac]

Revision: 14519
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14519&view=rev
Author:   vouchcac
Date: 2010-05-18 07:09:40 + (Tue, 18 May 2010)

Log Message:
---
2010-15-17 23:59 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
+ Finalized: all the three modes of selection programatically.
::toggleStreamSelection()No Key
::toggleColumnSelection()No Key
::toggleLineSelection()   == F11
::clearSelection()== Sh+F11
  If a selection mode is initiated by above three methods,
  it can only be exited by calling the same method again.
  During such selection process all other keys than navigable 
  keys will remain disabled. Mouse-move will also not work.
  Mouch click will work. If Column selection mode is ON,
  caret will not show up. Toolbar icon will not respond to 
  change such action. Once exited, previous normal behavior
  for stream and column selection will be available.

  Please test.
 

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h


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