Hello,

1. That would not be effective because this setting affects only data that fit 
in the cache (as set in preferences).
Data that are large than in-memory cache size (1GB max) would need to be 
flushed to disk in new format anyway.
End result would be a mixture that is readable by 5.27+ but not readable by any 
earier version.

2. Due to backward compatibility with existing plugins the AmiVar structure has 
to have the size of 8 bytes
(4 bytes type, 4 bytes data) and there is simply no room for that.
Implementing your suggestion means either breaking compatibility with existing 
plugins or
writing translation layer that will convert back and forth parameters from old 
style to new style with each
and every call back and forth. The second solution would eventually happen, but 
I did not want
to break everything just now. I had enough headache with changes that were 
requested and the amount of work
was tremendous despite the "visuals" did not change. This is not really 
something you do easily,
because ordinary people see "no advantage" because they see no new buttons in 
the UI, yet
the amount of work you do is huge.

Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message ----- 
From: "paultsho" <[email protected]>
To: <[email protected]>
Sent: Sunday, August 23, 2009 12:03 PM
Subject: [amibroker] Re: AmiBroker 5.28.0 BETA released


> Tomasz
> I have one suggestion and one request with regard to 5.28
>
> suggestion - Could you make "Ast to save changed data" checked as default for 
> the next few releases until people have grown used 
> to the new database format. Because if it not set, the new format would be 
> saved when we exit AB, regardless of whether we want it 
> saved or not. That was the first thing I did, and it took ages to get it back 
> in the previous format.
>
> request - even though you dont have a specific function that returns the 
> DateTime number in dll. I was able to recast DateTime() 
> from a pointer to float to a pointer to AmiDate and access the datetime for 
> each bar. obviously, this is no longer possible. Of 
> course I could use two functions Datenum and Timenum and combine them for 
> each bar. but that would be a waster of cpu cycles given 
> that you actually store the DATETIME in AmiDate format. Could we have a 
> functio that returns a 64 bits pointer to AmiDate or 
> alternatively DATE. It would make dll function writing for intraday bars, 
> especially tick bars a lot more efficient.
>
> Thanks
>
>
> --- In [email protected], "Tomasz Janeczko" <gro...@...> wrote:
>>
>> Hello,
>> AmiBroker 5.28.0 BETA released:
>>
>> http://www.amibroker.com/devlog/2009/08/22/amibroker-5-28-0-beta-released/
>>
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>>
>
>
>
>
> ------------------------------------
>
> **** IMPORTANT PLEASE READ ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> TO GET TECHNICAL SUPPORT send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> http://www.amibroker.com/feedback/
> (submissions sent via other channels won't be considered)
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> Yahoo! Groups Links
>
>
>

Reply via email to