Rick,
it would require too much work, sorry.
EMG
Board index FiveWin for Harbour/xHarbour Migrating to Harbour
Enrico,
You could use a function that does the job automatically:
oSheet:Cells( 1, 1 ):Value = MyCheckDate( ... )
function MyCheckDate( u )
return If( Empty( u ), nil, CToD( u ) )
You can modify it based on your needs.
Antonio,
ok, but I would have to check tons of lines of code to look for the places where to put that function.
As I already said: impractical... 
This is clearly an Harbour bug. We can assign any empty types except date. Illogical.
EMG
Enrico,
Do you get an error with Harbour on this code ?
oSheet:Cells( 1, 1 ):Value = CToD( "" )
Which error ?
What about using TRY ... CATCH ... END ? 
Antonio,
Too much work.
EMG
Antonio Linares wrote:Do you get an error with Harbour on this code ?
oSheet:Cells( 1, 1 ):Value = CToD( "" )
Which error ?
Error WINOLE/1006 (0x800A03EC): _VALUE (DOS Error -2147352567)
Called from TOLEAUTO:_VALUE(0)
Called from MAIN(11)Antonio Linares wrote:What about using TRY ... CATCH ... END ?
Too much work.
EMG
oSheet:Cells( 1, 1 ):Value = CToD( "" )
Isn't that a direct call to the Excel API? If so, it would seem that it is an Excel issue not a Harbour issue. But then, I don't understand why it would work with xHarbour unless the pre-processor is changing the code.
Any chance that you are comparing two different versions of Excel--one using Harbour and another with xHarbour?
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
James,
It makes no sense that we can assign all empty types except date, isn't it?
No, it's not the preprocessor, it's internal xHarbour OLE management that fixes the problem. Harbour should do the same, in my opinion.
No, sorry. But you can use my sample as it is. It's a complete sample.
EMG
James Bott wrote:oSheet:Cells( 1, 1 ):Value = CToD( "" )
Isn't that a direct call to the Excel API? If so, it would seem that it is an Excel issue not a Harbour issue.
It makes no sense that we can assign all empty types except date, isn't it?
James Bott wrote:But then, I don't understand why it would work with xHarbour unless the pre-processor is changing the code.
No, it's not the preprocessor, it's internal xHarbour OLE management that fixes the problem. Harbour should do the same, in my opinion.
James Bott wrote:Any chance that you are comparing two different versions of Excel--one using Harbour and another with xHarbour?
No, sorry. But you can use my sample as it is. It's a complete sample.
EMG
Enrico,
Its just a workaround, but what do you think if you use a modified function CToD() ?
If you agree on that, then I will help you to build it
Enrico,
Actually 0 and .f. are valid data, are they not? Are you saying they are converted to nil before putting the data into Excel?
What are you basing this on? I know that I have used third-party libraries (that Harbour does not have any knowledge of) to pass data in a similar manner. So, at least in this case, there is no processing by Harbour, unless maybe it is generic. Do you know for a fact that this is happening or are you making an assumption?
Anyway, does it make sense that we can assign all empty types except date? These all work:
oSheet:Cells( 1, 1 ):Value = ""
oSheet:Cells( 1, 1 ):Value = 0
oSheet:Cells( 1, 1 ):Value = .F.
Actually 0 and .f. are valid data, are they not? Are you saying they are converted to nil before putting the data into Excel?
No, it's not the preprocessor, it's internal xHarbour OLE management that fixes the problem. Harbour should do the same, in my opinion.
What are you basing this on? I know that I have used third-party libraries (that Harbour does not have any knowledge of) to pass data in a similar manner. So, at least in this case, there is no processing by Harbour, unless maybe it is generic. Do you know for a fact that this is happening or are you making an assumption?
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Antonio,
I thought of this too, but then it would be returning nil to the entire program and there are probably other places where this would crash, like in saving to a DBF.
Its just a workaround, but what do you think if you use a modified function CToD() ?
I thought of this too, but then it would be returning nil to the entire program and there are probably other places where this would crash, like in saving to a DBF.
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Antonio,
And what about
when birthdate field is empty? There's no way out other than fix Harbour...
EMG
Antonio Linares wrote:Its just a workaround, but what do you think if you use a modified function CToD() ?
If you agree on that, then I will help you to build it
And what about
oSheet:Cells( 1, 1 ):Value = FIELD -> birthdatewhen birthdate field is empty? There's no way out other than fix Harbour...
EMG
Antonio,
Yes, just like CTOD( "" ).
This is from xHarbour hbwinole.c:
EMG
James Bott wrote:Anyway, does it make sense that we can assign all empty types except date? These all work:
oSheet:Cells( 1, 1 ):Value = ""
oSheet:Cells( 1, 1 ):Value = 0
oSheet:Cells( 1, 1 ):Value = .F.
Actually 0 and .f. are valid data, are they not?
Yes, just like CTOD( "" ).
James Bott wrote:Are you saying they are converted to nil before putting the data into Excel?
No, it's not the preprocessor, it's internal xHarbour OLE management that fixes the problem. Harbour should do the same, in my opinion.
What are you basing this on? I know that I have used third-party libraries (that Harbour does not have any knowledge of) to pass data in a similar manner. So, at least in this case, there is no processing by Harbour, unless maybe it is generic. Do you know for a fact that this is happening or are you making an assumption?
This is from xHarbour hbwinole.c:
case HB_IT_DATE:
if( pItem->item.asDate.value == 0 )
{
PHB_V_VT( pVariant ) = VT_NULL;
}EMG
Friends
We are all beating around the bush.
Let us not think that EMG does not know workarounds or that he is not capable of finding on his own. No point in keep advising him to implement work arounds.
The fact is that this is bug in Harbour well known for a long time. This is a problem not only for excel but also for ADO.
His point is that he has large existing code and it is extremely difficult to implement work arounds everywhere. It is true. Imagine that any work around is to be implemented for every assignment.
He is speaking not only on his own behalf. Rather on behalf of many programmers who want to migrate.
We are all beating around the bush.
Let us not think that EMG does not know workarounds or that he is not capable of finding on his own. No point in keep advising him to implement work arounds.
The fact is that this is bug in Harbour well known for a long time. This is a problem not only for excel but also for ADO.
His point is that he has large existing code and it is extremely difficult to implement work arounds everywhere. It is true. Imagine that any work around is to be implemented for every assignment.
He is speaking not only on his own behalf. Rather on behalf of many programmers who want to migrate.
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
Hello,
So I beleive that the better solution will be to post those comments in the Harbour Developer forum.
Thanks.
Rao,
Thank you! Perfect!
EMG
nageswaragunupudi wrote:Friends
We are all beating around the bush.
Let us not think that EMG does not know workarounds or that he is not capable of finding on his own. No point in keep advising him to implement work arounds.
The fact is that this is bug in Harbour well known for a long time. This is a problem not only for excel but also for ADO.
His point is that he has large existing code and it is extremely difficult to implement work arounds everywhere. It is true. Imagine that any work around is to be implemented for every assignment.
He is speaking not only on his own behalf. Rather on behalf of many programmers who want to migrate.
Thank you! Perfect!
EMG