> TGenClass<> is not a full type, only TGenClass is, so you need to
use - in your example - TSpecType(Obj)
Yes, I'm aware of this. The problem is I don't know TSpecType which I said
the last note. It could be any user defined specialization of TGenClass.
Back to above code, but closer to my actual
I'm currently looking into ways to write all the objects in my
application to a stream. I don't expect to have more than one or two
hundred objects, so a fully-fledged framework like tiOPF seems like
overkill. I am trying to find out what the RTL offers to solve this kind
of problem.
I came ac
On 30.10.2015 20:10, leledumbo wrote:
Consider the following:
type
generic TGenClass = class
...
end;
TSpecType = specialize TGenClass;
TMyClass = class
FST: TSpecType;
procedure p;
published
ST: TSpecType read FST write FST;
end;
procedure TMyClass.p;
...
Consider the following:
type
generic TGenClass = class
...
end;
TSpecType = specialize TGenClass;
TMyClass = class
FST: TSpecType;
procedure p;
published
ST: TSpecType read FST write FST;
end;
procedure TMyClass.p;
...
begin
PropCount := GetPropList(Self,Props);
fo
On 10/30/2015 12:06 PM, Jonas Maebe wrote:
Frederic Da Vitoria wrote on Fri, 30 Oct 2015:
2015-10-30 16:39 GMT+01:00 Jonas Maebe :
Never ever use CRC32 in a crypto context, it's completely unsuited and
easily cracked. The subject of this thread is already about finding an
implementation for
On 10/30/2015 11:30 AM, Frederic Da Vitoria wrote:
2015-10-30 0:33 GMT+01:00 mailto:wkitt...@windstream.net>>:
On 10/29/2015 01:08 PM, Frederic Da Vitoria wrote:
Good point. I'd even ask the question: do you really need to store the
passwords? IOW, do you want to be able to
Frederic Da Vitoria wrote on Fri, 30 Oct 2015:
2015-10-30 16:39 GMT+01:00 Jonas Maebe :
Never ever use CRC32 in a crypto context, it's completely unsuited and
easily cracked. The subject of this thread is already about finding an
implementation for scrypt, which is a (at this time considered)
2015-10-30 16:39 GMT+01:00 Jonas Maebe :
>
> Frederic Da Vitoria wrote on Fri, 30 Oct 2015:
>
> Do you really need to compare them or simply to validate them? I ask
>> because in one project I worked on for an insurance company, we were
>> forbidden to store the passwords. We stored only a kind of
Frederic Da Vitoria wrote on Fri, 30 Oct 2015:
Do you really need to compare them or simply to validate them? I ask
because in one project I worked on for an insurance company, we were
forbidden to store the passwords. We stored only a kind of checksum for
them. With something like CRC32 or eve
2015-10-30 0:33 GMT+01:00 :
> On 10/29/2015 01:08 PM, Frederic Da Vitoria wrote:
>
>> Good point. I'd even ask the question: do you really need to store the
>> passwords? IOW, do you want to be able to send them back to the user? Or
>> do
>> you only need to check them?
>>
>
> in the use case bein
wkitt...@windstream.net wrote:
On 10/29/2015 01:08 PM, Frederic Da Vitoria wrote:
Good point. I'd even ask the question: do you really need to store the
passwords? IOW, do you want to be able to send them back to the user?
Or do
you only need to check them?
in the use case being studied, pas
In our previous episode, Klaus Hartnegg said:
> With password
> there would have to be a plan B in case users forget a password.
And now you need a plan B for when the user changes email address.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.o
Am 29.10.2015 um 18:08 schrieb Frederic Da Vitoria:
I'd even ask the question: do you really need to store the
passwords? IOW, do you want to be able to send them back to the user? Or
do you only need to check them?
My latest access system does not use passwords at all. The server sends
the us
13 matches
Mail list logo
