Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?

2013-10-27 Thread Bart
On 10/27/13, Marco van de Voort wrote: > For windows there is winutils.iswindowsadmin(), for unix likes there is > fpgeteuid (which should return zero for root). Thanks a lot. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lis

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marco van de Voort
In our previous episode, Marcos Douglas said: > Yes and how I still use D7 at work I still have this problem. > This problem happen not only for unit names but component names too. I > can not register two components with the same name. True. But is maybe because RTTI (and .classname) didn't allow

Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?

2013-10-27 Thread Marco van de Voort
In our previous episode, Bart said: > > I thought of trying to write to a "protected" location (/etc/something > on linux, C:\ProgramData\something on Windows), but the problem is > that Windows virtualizes these calls (it'll end up somewhere lse, > where your program will never find it again), so

[fpc-pascal] How to detect if my program is running with root/elevated privileges?

2013-10-27 Thread Bart
Hi, In my program I have some functions that must only be enabled if the program is invoked as root (linux) / administrator (windows). Is there some cross platform way to detect this? I thought of trying to write to a "protected" location (/etc/something on linux, C:\ProgramData\something on Win

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marcos Douglas
On Sun, Oct 27, 2013 at 12:04 PM, Fabrício Srdic wrote: > 2013/10/27 Marco van de Voort >> >> In our previous episode, Marcos Douglas said: >> > > Namespaces are only for pseudo hierarchical disambiguation of unit >> > > names in >> > > Pascal. >> > >> > Very true. I agree with everything. >> > B

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marcos Douglas
On Sun, Oct 27, 2013 at 11:59 AM, Marco van de Voort wrote: > In our previous episode, Marcos Douglas said: >> > Namespaces are only for pseudo hierarchical disambiguation of unit names in >> > Pascal. >> >> Very true. I agree with everything. >> BUT, IMHO, the only problem is if you have two 3rd

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Fabrício Srdic
2013/10/27 Marco van de Voort > In our previous episode, Marcos Douglas said: > > > Namespaces are only for pseudo hierarchical disambiguation of unit > names in > > > Pascal. > > > > Very true. I agree with everything. > > BUT, IMHO, the only problem is if you have two 3rd frameworks that use >

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marco van de Voort
In our previous episode, Marcos Douglas said: > > Namespaces are only for pseudo hierarchical disambiguation of unit names in > > Pascal. > > Very true. I agree with everything. > BUT, IMHO, the only problem is if you have two 3rd frameworks that use > the same unit name. In that case I can not ad

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marcos Douglas
On Sun, Oct 27, 2013 at 11:13 AM, Marco van de Voort wrote: > In our previous episode, Fabr?cio Srdic said: >> > used in Java and .NET as either languages don't have "units". >> > Adding "features" just because "enterpise-class dev platforms" have them >> > is more marketing move, than actual tech

Re: [fpc-pascal] WHY compiler should be public?

2013-10-27 Thread Xiangrong Fang
2013/10/27 Michael Van Canneyt > > > Ah. The 'private' constructor is called FROM ANOTHER INSTANCE. You didn't > say that. > > That currently can't be done. > > Michael. ​So, in this case, can/should I make my constructor private, ignoring the warning, or just make it public to "play it safe"?

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Fabrício Srdic
2013/10/27 Marco van de Voort > In our previous episode, Fabr?cio Srdic said: > > > used in Java and .NET as either languages don't have "units". > > > Adding "features" just because "enterpise-class dev platforms" have > them > > > is more marketing move, than actual technical need. > > > > > >

Re: [fpc-pascal] Namespaces Support

2013-10-27 Thread Marco van de Voort
In our previous episode, Fabr?cio Srdic said: > > used in Java and .NET as either languages don't have "units". > > Adding "features" just because "enterpise-class dev platforms" have them > > is more marketing move, than actual technical need. > > > > We can't nest units to form a hierarchical co

Re: [fpc-pascal] WHY compiler should be public?

2013-10-27 Thread Sven Barth
Am 27.10.2013 02:12 schrieb "Xiangrong Fang" : > Also, > > I don't understand why this does not work: > > f := TFileStream.Create; > > I know that TFileStream's Create require a file name parameter, but as TFileStream is inherited from TObject, which has a Create without parameter. This is why I

Re: [fpc-pascal] WHY compiler should be public?

2013-10-27 Thread Sven Barth
Am 27.10.2013 12:18 schrieb "Michael Van Canneyt" : >> Also, >> I don't understand why this does not work: >> >> f := TFileStream.Create; >> >> I know that TFileStream's Create require a file name parameter, but as TFileStream is inherited from TObject, which has a Create without parameter. This

Re: [fpc-pascal] WHY compiler should be public?

2013-10-27 Thread Michael Van Canneyt
On Sun, 27 Oct 2013, Xiangrong Fang wrote: 2013/10/25 Michael Van Canneyt Why not simply make it a procedure that is called by ver-2 and ver-3. If it cannot be called directly from external code, and will called only from inside a visible consructor, there is simply no reason to make