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

[Mindaugas Kavaliauskas]

On 2010.05.04 18:02, Pritpal Bedi wrote:

Line Block:  does it pertains to a single line always ?


Yes, if I understand your question. Starting and ending line selection 
mark (without any cursor movement), marks current line.
If DOWN (or UP) is pressed between start mark and end mark, then two 
lines are selected.



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

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> OK, I've understood the misunderstanding.
> 
> I just call selection modes:
> 1) Line
> 2) Stream
> 3) Column
> 
> In all 3 cases the selected part of is called block. In this case 
> "selection" is a synonym to "selected block" or just "block". Just look 
> at Menu->Edit->Block. I expect these actions to be valid for all 
> selection modes, not only column blocks. I guess you understand word 
> "block" the same way, because these menu items were implemented before 
> column blocks.
> 
> So, it would nice to have persistent blocks for all three selection 
> modes. Though, I guess, this requires some tricks like subclassing at 
> C++ level, etc.
> 

Oh, now I am clear.
Though it is tricky, but let me try, hopefully I will implement.

Line Block:  does it pertains to a single line always ?


-
 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-14417-trunk-harbour-tp4994458p5003762.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:[14417] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,

On 2010.05.04 16:58, Pritpal Bedi wrote:

After any cursor movement, block is not marked any more :( I've rebuild
the whole contrib, and hbide. Maybe I have to do something more?

This is valid for block selection mode.
Stream selection does not have it.
If it is block selection mode, it is persistent, I have again checked it,
and behaves correct. No other setting is required except that
"Toggle Selection Mode" icon should be visible depressed.

Please let me know my observation is ok or not.


OK, I've understood the misunderstanding.

I just call selection modes:
1) Line
2) Stream
3) Column

In all 3 cases the selected part of is called block. In this case 
"selection" is a synonym to "selected block" or just "block". Just look 
at Menu->Edit->Block. I expect these actions to be valid for all 
selection modes, not only column blocks. I guess you understand word 
"block" the same way, because these menu items were implemented before 
column blocks.


So, it would nice to have persistent blocks for all three selection 
modes. Though, I guess, this requires some tricks like subclassing at 
C++ level, etc.



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

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
>> 2. Get cursor out of this area either by clicking at the other row or
>> with
>> arrows keys.
> 
> After any cursor movement, block is not marked any more :( I've rebuild 
> the whole contrib, and hbide. Maybe I have to do something more?
> 

This is valid for block selection mode.
Stream selection does not have it.
If it is block selection mode, it is persistent, I have again checked it,
and behaves correct. No other setting is required except that 
"Toggle Selection Mode" icon should be visible depressed.

Please let me know my observation is ok or not.


-
 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-14417-trunk-harbour-tp4994458p5003468.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:[14417] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,


On 2010.05.04 16:31, Pritpal Bedi wrote:

 + Implemented: persistent blocks and cut/copy/paste operations
   across files and locations within the same file.


Perhaps this is implemented in .cpp level only yet. I can not find a way
to switch persistent block mode on.


If I am taking it in right perspective, persistent block means a selected
area
remains selected until another block operation is initiated, right ?
If yes, then this is exactly how it is implemented now.

To illustrate:
1. Select a block either with Sh+NavableKeys or mouse.


OK.


2. Get cursor out of this area either by clicking at the other row or with
arrows keys.


After any cursor movement, block is not marked any more :( I've rebuild 
the whole contrib, and hbide. Maybe I have to do something more?



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

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> I do not know the "correct" key mappings for various operations. It is a 
> question of mappings, but I think it's enough to make all actions 
> mappable and prepare a few sets of mappings. Let's say: MultiEdit 
> compatible, xMate compatible, and "common Windows" key mapping. If move 
> block has not key in common windows applications (because native windows 
> controls does not have persistent blocks), we can leave move block 
> operation unassigned.
> 

I have made it simpler. 



> The idea of persistent block is that block remains marked after 
> navigation keys are pressed!
> 

Yep it should behave like this.



> If persistent block mode is switched off, blocks is deactivated/unmarked 
> after any cursor movement. If persistent block mode is switch on, there 
> is a special unmark operation. If is Ctrl+Shift+F7 in standard MultiEdit 
> key mapping. But I usually unmark block by Shift+Up,Down, i.e. by 
> marking another empty block.
> 

This is exactly how it is implemented now.



>>   * contrib/hbqt/hbqt_hbqplaintextedit.cpp
>>   * contrib/hbqt/hbqt_hbqplaintextedit.h
>>   * contrib/hbide/ideeditor.prg
>>   * contrib/hbide/ideshortcuts.prg
>> + Implemented: persistent blocks and cut/copy/paste operations
>>   across files and locations within the same file.
> 
> Perhaps this is implemented in .cpp level only yet. I can not find a way 
> to switch persistent block mode on.
> 

If I am taking it in right perspective, persistent block means a selected
area
remains selected until another block operation is initiated, right ?
If yes, then this is exactly how it is implemented now.

To illustrate:

1. Select a block either with Sh+NavableKeys or mouse.
2. Get cursor out of this area either by clicking at the other row or with
arrows keys.
3. Start typing, see that block remains intact.
4. Scroll past the block and bring it back in view, it is intact.
5. Click on other editor instance and do the same.
6. Go back and forth both editing instances and check if block still exists.
7. Issue Ctrl+C while in source having selected block.
8. Select other instance and press Ctrl+V, check block copntents copied
here.

Or I am missing to decipher persistence ?

-
 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-14417-trunk-harbour-tp4994458p5003361.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:[14417] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,



I have just realized that blocks are not copyable to other file.
Will fix in a while. Moving the block is something new to me and is easy.
Which key should be designated to move, Ctrl+M ?


I do not know the "correct" key mappings for various operations. It is a 
question of mappings, but I think it's enough to make all actions 
mappable and prepare a few sets of mappings. Let's say: MultiEdit 
compatible, xMate compatible, and "common Windows" key mapping. If move 
block has not key in common windows applications (because native windows 
controls does not have persistent blocks), we can leave move block 
operation unassigned.




One block per file can remain persistent until a navigation key is not
presses.


The idea of persistent block is that block remains marked after 
navigation keys are pressed!




Line blocks marks whole lines, so, you do not need to move cursor to the
first column.


Ok, got it. Is easy to implement. But again it is an issue when to
deactivate.
I will think over this issue.


If persistent block mode is switched off, blocks is deactivated/unmarked 
after any cursor movement. If persistent block mode is switch on, there 
is a special unmark operation. If is Ctrl+Shift+F7 in standard MultiEdit 
key mapping. But I usually unmark block by Shift+Up,Down, i.e. by 
marking another empty block.




  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
  * contrib/hbide/ideeditor.prg
  * contrib/hbide/ideshortcuts.prg
+ Implemented: persistent blocks and cut/copy/paste operations
  across files and locations within the same file.


Perhaps this is implemented in .cpp level only yet. I can not find a way 
to switch persistent block mode on.



Thanks, regards,
Mindaugas

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

[Massimo Belgrano]

VIsual Studio
Delphi
Eric pynton ide (made  in qt http://eric-ide.python-projects.org/)
Eclipse
and a good idea was defined by a waporware for visual fox pro: vfpstudio
http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,b71ea97e-8fb8-4401-ace4-b5a536fe0a37.aspx

2010/5/4 Antonio Maniero 

>
>> Pritpal, I think you need download and install some editors and IDEs to
>> have ideas and to learn how some features working. If you want I can suggest
>> some good example (closed and open source).
>>
>
>
>


-- 
Massimo Belgrano
___
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:[14417] trunk/harbour

[Antonio Maniero]

>
>
>
> I think MultiEdit has free 30-days evaluation. I really like functionality
> of this editor. Default functional keys mappings can seem unusual, but later
> you find it comfortable.
>
> Pritpal, I think you need download and install some editors and IDEs to
> have ideas and to learn how some features working. If you want I can suggest
> some good example (closed and open source).
>



>
> Thank, you for your efforts. After I look to C++ code, magic QT signal/slot
> binding, moc_*.cpp files, I start to think I know nothing about C++. Plain C
> is much more clear to me.
>
>
> Me too, Mindaugas! :-)


[]'s Maniero
___
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:[14417] trunk/harbour

[Antonio Maniero]

>
>
> I am following xMate and it has nothing like this. I think it should not be
> difficult once I know exact implementation details.
>
> Please, try to do a better product than xMate. Don't stay limited to xMate
limitations.


>
>
> > 2) I'm trying to use Setup->Keyboard mappings, but unable to find a way
> > to assign key for many toolbar buttons. I want to add key for "Toggle
> > selection mode" button.
> >
>
> Ok, it is also a candidate for public methods API.
> It will and some others will be committed today.
>
>
> This is a very tough request. Only for this reason, block copy/paste
> eluded me so long. I still do not know how to handle it unless QDocument
> is also sub-classed. This is on my todo list but am still at loss how to.
> Probably I have to spend more time on this feature.
>
>
> So subclass it! I think is the right way. You can have power trying work on
raw class.

I put my signature below of all Mindaugas suggestions. Some of
them optionally, of course.

[]'s Maniero
___
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:[14417] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> Persistent blocks remains marked after you move a cursor to another 
> place. You can mark block. Move cursor to another place and copy (or 
> move) block here without intermediate storage to clipboard. You can have 
> marked blocks in various open files and do inter-window block copy/move 
> of blocks.
> 

I have just realized that blocks are not copyable to other file.
Will fix in a while. Moving the block is something new to me and is easy.
Which key should be designated to move, Ctrl+M ?

One block per file can remain persistent until a navigation key is not
presses.
So to move somewhere in the same file, navigation key is inevatible, 
so I am thinking how some other way to deactivate it. Any ideas ?



> Line blocks marks whole lines, so, you do not need to move cursor to the 
> first column.
> 

Ok, got it. Is easy to implement. But again it is an issue when to
deactivate.
I will think over this issue.



> MultiEdit has tree types of blocks: Line, Stream, Column. It also 
> supports persistent blocks.
> 
> Let's say I need to change code:
> CASE 'a':
>::doA()
>EXIT
>::doB()
>EXIT
> to:
> CASE 'a':
>::doA()
>EXIT
> CASE 'b':
>::doB()
>EXIT
> and my cursor is at letter 'a':
> 
> In MultiEdit I would do:
>F7 (start line block mark)
>F7 (end line block mark) (current line remains marked)
>Down
>Down
>Down
>F8 (copy block)
>b
>Del
> 
> Using stream blocks:
>Home
>Shift + Down
>Ctrl + C
>Down
>Down
>Ctrl + V
>End
>Left
>Left
>Left (position restored to letter 'a')
>b
>Del
> 
> I think MultiEdit has free 30-days evaluation. I really like 
> functionality of this editor. Default functional keys mappings can seem 
> unusual, but later you find it comfortable.
> 

I will try multi-edit though I have a very limited time schedule.
Above all the three modes, I will hopefully be able to implement.



> I've managed to bind keystoke to script:
>::execAction("SelectionMode")
> Though I expect a litte different logic for block marking. It would be 
> nice to have a separate keys, to start different type marking. But I can 
> live with current behaviour.
> 

:-) I know you are capable of deep insights.
I am about to include all in publick api.



> Thank, you for your efforts. After I look to C++ code, magic QT 
> signal/slot binding, moc_*.cpp files, I start to think I know nothing 
> about C++. Plain C is much more clear to me.
> 

I also thought you way until I started with C++ classes.
Believe me it is lot simpler than I ever thought and syntax is very 
near to Harbour's.



> But this does not disables ESC action. Sometimes I press extra ESC then 
> closing a few level modal dialogs, etc. And this ESC closes open files.
> 

Fixed. The key was there since start of hbIDE project
and hanged around till today.


-
 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-14417-trunk-harbour-tp4994458p5000821.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:[14417] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,


On 2010.05.04 00:07, Pritpal Bedi wrote:

Thanks, for column blocks! Do you have plans for doing blocks persistent
and implementing line blocks? :)

Can you please explain a little about your idea of persistency and line
blocks.


Persistent blocks remains marked after you move a cursor to another 
place. You can mark block. Move cursor to another place and copy (or 
move) block here without intermediate storage to clipboard. You can have 
marked blocks in various open files and do inter-window block copy/move 
of blocks.


Line blocks marks whole lines, so, you do not need to move cursor to the 
first column.


MultiEdit has tree types of blocks: Line, Stream, Column. It also 
supports persistent blocks.


Let's say I need to change code:
   CASE 'a':
  ::doA()
  EXIT
  ::doB()
  EXIT
to:
   CASE 'a':
  ::doA()
  EXIT
   CASE 'b':
  ::doB()
  EXIT
and my cursor is at letter 'a':

In MultiEdit I would do:
  F7 (start line block mark)
  F7 (end line block mark) (current line remains marked)
  Down
  Down
  Down
  F8 (copy block)
  b
  Del

Using stream blocks:
  Home
  Shift + Down
  Ctrl + C
  Down
  Down
  Ctrl + V
  End
  Left
  Left
  Left (position restored to letter 'a')
  b
  Del

I think MultiEdit has free 30-days evaluation. I really like 
functionality of this editor. Default functional keys mappings can seem 
unusual, but later you find it comfortable.




2) I'm trying to use Setup->Keyboard mappings, but unable to find a way
to assign key for many toolbar buttons. I want to add key for "Toggle
selection mode" button.

Ok, it is also a candidate for public methods API.
It will and some others will be committed today.


I've managed to bind keystoke to script:
  ::execAction("SelectionMode")
Though I expect a litte different logic for block marking. It would be 
nice to have a separate keys, to start different type marking. But I can 
live with current behaviour.




3) I want to be able to move cursor beyond end of line, i.e., I do not
want to jump cursor to first column on empty lines and I do not want to
enter a lot of spaces for indented source code lines. END key could be
used, to position cursor at the exact end of line.


This is a very tough request. Only for this reason, block copy/paste
eluded me so long. I still do not know how to handle it unless QDocument
is also sub-classed. This is on my todo list but am still at loss how to.
Probably I have to spend more time on this feature.


Thank, you for your efforts. After I look to C++ code, magic QT 
signal/slot binding, moc_*.cpp files, I start to think I know nothing 
about C++. Plain C is much more clear to me.




This can be achived right now:
Name: Close
Key:   F4
CtrlChecked
Script:  ::close() [ Or double click on Close() 'Public methods' list. ]

Click on 

To test:
Click inside an editing instance; press Ctrl+F4
You are done with.


But this does not disables ESC action. Sometimes I press extra ESC then 
closing a few level modal dialogs, etc. And this ESC closes open files.



Thanks, 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:[14417] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> Yes, I've just copied hbide.exe into qt bin directory, because this 
> directory is not in the path and qt*.dlls are not found otherwise. Long 
> time ago this worked for me. I see no problem, that hbide requires some 
> more external resources, but infomative message would be better than 
> RTE. I guess Viktor has just committed the fix.
> 

Yep, Viktor has done it.



> Thanks, for column blocks! Do you have plans for doing blocks persistent 
> and implementing line blocks? :)
> 

Can you please explain a little about your idea of persistency and line
blocks.
I am following xMate and it has nothing like this. I think it should not be 
difficult once I know exact implementation details.



> Ok, I can live without persistent blocks and line blocks, but a few 
> things is very uncomfortable (or I do not know how to configure it):
> 

I will be glad to set things right.



> 1) ESC closes current window. Can I attach Ctrl+F4 for this action 
> instead of ESC?
> 

I should include it as a public method.
Will do in a momemnt.



> 2) I'm trying to use Setup->Keyboard mappings, but unable to find a way 
> to assign key for many toolbar buttons. I want to add key for "Toggle 
> selection mode" button.
> 

Ok, it is also a candidate for public methods API.
It will and some others will be committed today.



> 3) I want to be able to move cursor beyond end of line, i.e., I do not 
> want to jump cursor to first column on empty lines and I do not want to 
> enter a lot of spaces for indented source code lines. END key could be 
> used, to position cursor at the exact end of line.
> 

This is a very tough request. Only for this reason, block copy/paste 
eluded me so long. I still do not know how to handle it unless QDocument 
is also sub-classed. This is on my todo list but am still at loss how to.
Probably I have to spend more time on this feature.



-
 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-14417-trunk-harbour-tp4994458p5000192.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:[14417] trunk/harbour

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> 1) ESC closes current window. Can I attach Ctrl+F4 for this action 
> instead of ESC?
> 

This can be achived right now:

Name: Close
Key:   F4
CtrlChecked
Script:  ::close() [ Or double click on Close() 'Public methods' list. ]

Click on 

To test: 
Click inside an editing instance; press Ctrl+F4
You are done with.


-
 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-14417-trunk-harbour-tp4994458p5000223.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:[14417] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,



This error can only be there if hbide/resources/funclist.uic
is missing. I know your uncanny attention to details and hence
assume that you have compiled hbIDE at its standard location.
OR you are executing hbIDE from location without "resources"
subfolder and contents to from hbIDE.exe.


Yes, I've just copied hbide.exe into qt bin directory, because this 
directory is not in the path and qt*.dlls are not found otherwise. Long 
time ago this worked for me. I see no problem, that hbide requires some 
more external resources, but infomative message would be better than 
RTE. I guess Viktor has just committed the fix.


Thanks, for column blocks! Do you have plans for doing blocks persistent 
and implementing line blocks? :)


Ok, I can live without persistent blocks and line blocks, but a few 
things is very uncomfortable (or I do not know how to configure it):


1) ESC closes current window. Can I attach Ctrl+F4 for this action 
instead of ESC?
2) I'm trying to use Setup->Keyboard mappings, but unable to find a way 
to assign key for many toolbar buttons. I want to add key for "Toggle 
selection mode" button.
3) I want to be able to move cursor beyond end of line, i.e., I do not 
want to jump cursor to first column on empty lines and I do not want to 
enter a lot of spaces for indented source code lines. END key could be 
used, to position cursor at the exact end of line.



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

[Pritpal Bedi]

Mindaugas Kavaliauskas wrote:
> 
> thanks for this feature. It made me try to compile hbide after long 
> time, but:
> 

Thanks Mindaugas.
Your participation will be extremely valuable.



> ---
> Run-time Error!
> ---
> Error BASE/1132  Bound error: array access
> Called from HBQTUI:Q_TABLEFUNCLIST(0)
> Called from IDEFUNCTIONS:BUILDHEADER(210)
> Called from IDEFUNCTIONS:CREATE(146)
> Called from HBIDE:CREATE(356)
> Called from MAIN(102)
> ---
> OK
> ---
> 

This error can only be there if hbide/resources/funclist.uic
is missing. I know your uncanny attention to details and hence 
assume that you have compiled hbIDE at its standard location.
OR you are executing hbIDE from location without "resources"
subfolder and contents to from hbIDE.exe.

Let me know if it helped.
place.

-
 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-14417-trunk-harbour-tp4994458p4998518.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