f



Access parameters and accessibility

I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
difficulties to understand the chapter about access parameters.
In chapter 10.7 on pages 197/198 he writes:

---
An access parameter can be passed on to another access parameter; 
typically the accessibility indication is passed on unchanged but in the 
unusual circumstance where the called subprogram is internal to the 
calling subprogram, the accessibility level is replaced by that of the 
(statically known) formal calling parameter if less than the original 
actual parameter.
---

Could someone give an example/explanation where this rule is used?
I tried to read the RM. Chapter 3.10.2 seems to be the right one but I 
don't understand it either...

Thanks in advance,

Michael
0
Michael
12/15/2014 4:52:46 PM
comp.lang.ada 8774 articles. 2 followers. Post Follow

37 Replies
1035 Views

Similar Articles

[PageSpeed] 29

On Mon, 15 Dec 2014 17:52:46 +0100, Michael B. wrote:

> I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
> difficulties to understand the chapter about access parameters.
> In chapter 10.7 on pages 197/198 he writes:
> 
> ---
> An access parameter can be passed on to another access parameter; 
> typically the accessibility indication is passed on unchanged but in the 
> unusual circumstance where the called subprogram is internal to the 
> calling subprogram, the accessibility level is replaced by that of the 
> (statically known) formal calling parameter if less than the original 
> actual parameter.
> ---
> 
> Could someone give an example/explanation where this rule is used?

The rule is: don't ever use this.

Accessibility information is a booby trap placed to blow up your program
later, when you expect it least.

If you know what you are doing, you should when you pass a pointer around,
kill the accessibility information where possible, e.g. by converting to a
named access type, by using X.all'Unchecked_Access etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
12/15/2014 5:54:20 PM
On 12/15/2014 10:54 AM, Dmitry A. Kazakov wrote:
> 
> The rule is: don't ever use this.

I second this.

Anonymous access types, of which access parameters are instances, are a bad
idea. The language would be better off without them.

Public access types, and public subprograms with parameters of access types, are
also bad ideas.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36
0
Jeffrey
12/15/2014 6:48:42 PM
I don't want to use this stuff for my own code. My problem is that I 
want to understand object orientation in Ada. And this seems to be 
impossible without a complete understanding of access types in all flavors.

The OO chapters in Barnes' book assume that you have a deep 
understanding of access types. I don't. And therefore I'm stuck.

So would you please help me to understand this paragraph?

Regards

Michael


On 12/15/14 19:48, Jeffrey Carter wrote:
> On 12/15/2014 10:54 AM, Dmitry A. Kazakov wrote:
>>
>> The rule is: don't ever use this.
>
> I second this.
>
> Anonymous access types, of which access parameters are instances, are a bad
> idea. The language would be better off without them.
>
> Public access types, and public subprograms with parameters of access types, are
> also bad ideas.
>

0
Michael
12/15/2014 8:23:02 PM
On Mon, 15 Dec 2014 21:23:02 +0100, Michael B. wrote:

> I don't want to use this stuff for my own code. My problem is that I 
> want to understand object orientation in Ada. And this seems to be 
> impossible without a complete understanding of access types in all flavors.

You don't need access types to understand Ada's OO. Furthermore
accessibility checks and information has nothing to do with OO.

> So would you please help me to understand this paragraph?

It says that some information is hanged on the pointer's value implicitly.
The information contains a description of the context where the pointer was
obtained.

By this it violates manifest typing principle. It also does nominal typing.
Both are Ada's type system keystones.

The accessibility information is used on some other context where the
pointer is dereferenced or copied, in order to generate an exception
depending on the relation of this context to the origin context.

The rationale for this is that the pointer *might* become dangled, which in
most practical cases just wrong. The problem with the idea that the
decision is taken according to the pointer contexts, not the context of the
object itself (which would be impossible). So, basically, it is just an
arbitrary exception generator.

Since the thing sometimes generates exception and sometimes does not, it
also violates important OO principles, such as substitutability. Because it
makes the behavior context-dependent.

In short, it is a mess, the only thing you need to know about is how to
avoid it in your program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
12/15/2014 9:02:08 PM
>=20
> Could someone give an example/explanation where this rule is used?
> I tried to read the RM. Chapter 3.10.2 seems to be the right one but I=20
> don't understand it either...
>=20

As others have pointed out, anonymous access types are 'expert friendly' at=
 best, and there is a whole host of history and compromises as to why they =
are how they are, most of which are obsolete in 2012.  For 99% of situation=
s, you don't have to lose any sleep over any of this (though I disagree wit=
h the 'never ever ever' attitude of others).

However, long story short, using an 'access parameter' (i.e. an anonymous a=
ccess type as a subprogram parameter) requires passing along some meta-data=
 about the object for various esoteric situations when a runtime check migh=
t be required.  However, as the author points out, there are some (even rar=
er) cases where what would normally require a runtime check would be static=
ally known to be ok, and thus could be performed without risk.  That's all =
it's saying.

This is compiler detail, not a language rule, so I would doubt you would fi=
nd it in the LRM (perhaps in the AARM, as a note?)  If you are a masochist,=
 the same author produced a whitepaper back in the day going into much more=
 gory detail about all this (ACM Ada Letters, Jan/Feb 1995, page 45 specifi=
cally).

-sb

0
sbelmont700
12/16/2014 1:10:28 AM
"Michael B." <michaelb@example.com> wrote in message 
news:m6n3kr$t51$1@speranza.aioe.org...
> I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
> difficulties to understand the chapter about access parameters.
> In chapter 10.7 on pages 197/198 he writes:
>
> ---
> An access parameter can be passed on to another access parameter; 
> typically the accessibility indication is passed on unchanged but in the 
> unusual circumstance where the called subprogram is internal to the 
> calling subprogram, the accessibility level is replaced by that of the 
> (statically known) formal calling parameter if less than the original 
> actual parameter.
> ---
>
> Could someone give an example/explanation where this rule is used?
> I tried to read the RM. Chapter 3.10.2 seems to be the right one but I 
> don't understand it either...

We in the ARG call discussing accessibility a "trip to the Heart of 
Darkness", and indeed, 3.10.2 is now informally called the "Heart of 
Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the 
desperate or foolhardy venture there.

I had heaard about the issue that John mentions in this paragraph, but I 
never understood it (I don't think Janus/Ada does it). I've had it explained 
to me a couple of times, and I sort of understand it, but you'd have to pay 
me to spend an hour finding an example and writing up an appropriate 
explanation. It's that draining - I wouldn't do it for free. Sorry.

Besides, I agree with the others that it has nothing to do with OOP. Claw 
only uses anonymous access parameters to get the effect of in out parameters 
in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry 
noted, it doesn't work very well. Anonymous access parameters: just say no!!

Finally, the model that John is talking about isn't sufficient to implement 
dynamic accessibility checks in Ada 2005 or Ada 2012. He's really talking 
about an implementation short-cut that should be irrelevant to understanding 
the feature anyway. (That is, it doesn't even belong in his book.) And that 
short-cut doesn't work. Indeed, no Ada compiler has ever actually 
implemented correct accessibility checking for Ada 2005 or later. We believe 
it is possible (Steve Baird and I have worked out correct implementation 
models, but no one has tried either yet). We're supposed to be writing an 
Ada-Europe paper -- but of course that requires a trip to the Heart of 
Darkness, and neither of us has been in much a hurry to take that trip!

The only thing to worry about vis-a-vis dynamic accessibility checking is 
that the object has to have a lifetime the same or longer than the access 
type. How that's implemented should not matter (unless of course you are 
trying to fix a compiler bug -- something most people here aren't going to 
do).

                                             Randy.


0
Randy
12/16/2014 7:45:06 AM
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-111946393-1418719359=:7909
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.11.1412160942451.7909@debian>

On Tue, 16 Dec 2014, Randy Brukardt wrote:

> Indeed, no Ada compiler has ever actually implemented correct=20
> accessibility checking for Ada 2005 or later.

Could you envision the ARG to drop anonymous access parameters, or at=20
least severely restrict their usage, in the next language revision?

If a language feature has not yet been properly implemented, you don't=20
break working code by dropping this feature.

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universit=E4t Weimar, Germany--
--8323329-111946393-1418719359=:7909--
0
Stefan
12/16/2014 8:48:35 AM
On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> Anonymous access parameters: just say no!!

I still believe a case could be made for anonymous access to subprogram
parameters.

Generics and interfaces could of course be used instead of them, but I
feel they are often more cumbersome to use.


Natasha
0
Natasha
12/16/2014 9:08:40 AM
On Tue, 16 Dec 2014 09:08:40 +0000 (UTC), Natasha Kerensikova wrote:

> On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
>> Anonymous access parameters: just say no!!
> 
> I still believe a case could be made for anonymous access to subprogram
> parameters.

There should never have been such thing. Subprograms should have been an
in-parameter (90% of cases) or else a named access type (10% of cases).

Others already said that anonymous access was an workaround. There is the
list of issues it deals with:

1. lack of in-out parameters of functions
2. missing downward closures (subprograms as in-parameters)
3. unwillingness to implement full multiple inheritance (so mix-ins)
4. broken object construction (so the Rosen's trick to re-dispatch and also
for #2)
5. non-tagged task and PO types (so, aggregation + an access to the
container as a discriminant)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
12/16/2014 10:00:48 AM
On 12/16/14 02:10, sbelmont700@gmail.com wrote:
> If you are a masochist, the same author produced a whitepaper back in
> the day going into much more gory detail about all this (ACM Ada
> Letters, Jan/Feb 1995, page 45 specifically).

Until yesterday I thought that I'm no masochist, but when I read the 
answers of other people to my question I'm not sure anymore ;-).

I tried to find the paper you mentioned. But the only source I found is 
the ACM website where I can buy it. Is this text somewhere publicly 
available?

Regards,

Michael
0
Michael
12/16/2014 1:57:48 PM
On 16.12.14 14:57, Michael B. wrote:
> On 12/16/14 02:10, sbelmont700@gmail.com wrote:
>> If you are a masochist, the same author produced a whitepaper back in
>> the day going into much more gory detail about all this (ACM Ada
>> Letters, Jan/Feb 1995, page 45 specifically).
>
> Until yesterday I thought that I'm no masochist, but when I read the answers of other people to my question I'm not sure anymore ;-).
>
> I tried to find the paper you mentioned. But the only source I found is the ACM website where I can buy it. Is this text somewhere publicly available?

The ACM library site states that a SIGAda membership
and a (free) ACM web account provide for free access.
I can't tell whether the "and" is semantically an "or",
but if you have both, they will do as promised.

I reckon the next university library has it, too, if not on
paper then as a scanned article, delivered as copy or electronically.

0
Georg
12/16/2014 2:12:46 PM
Natasha Kerensikova <lithiumcat@instinctive.eu> writes:

> On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
>> Anonymous access parameters: just say no!!
>
> I still believe a case could be made for anonymous access to subprogram
> parameters.

Yes, that's a completely different feature, and won't get you in any
trouble.  But those are conceptually subprograms, not pointers; the
syntax should be:

    procedure P(X: procedure ...

instead of the noisy:

    procedure P(X: not null access procedure ...

> Generics and interfaces could of course be used instead of them, but I
> feel they are often more cumbersome to use.

Yes.

Now what we need is lambdas.

- Bob
0
Robert
12/16/2014 2:57:31 PM
On 12/16/14 08:45, Randy Brukardt wrote:
> We in the ARG call discussing accessibility a "trip to the Heart of
> Darkness", and indeed, 3.10.2 is now informally called the "Heart of
> Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the
> desperate or foolhardy venture there.

Heart of Darkness?! When reading this part of the ARM it felt a little 
bit weird. But I had no idea it could be *that* bad ;-).

> I had heaard about the issue that John mentions in this paragraph, but I
> never understood it (I don't think Janus/Ada does it). I've had it explained
> to me a couple of times, and I sort of understand it, but you'd have to pay
> me to spend an hour finding an example and writing up an appropriate
> explanation. It's that draining - I wouldn't do it for free. Sorry.

Does that mean I should give up on that issue as I will never be able to 
understand it?

> Besides, I agree with the others that it has nothing to do with OOP. Claw
> only uses anonymous access parameters to get the effect of in out parameters
> in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
> noted, it doesn't work very well. Anonymous access parameters: just say no!!

How can I avoid them when they are heavily used in so many libraries?
E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
examples of the usage of anonymous access parameters.
You could argue that this is bad design, but rewriting all this code is 
not really an option for me.
And compared to writing GUIs in plain C it seems to be the lesser of two 
evils.

> Finally, the model that John is talking about isn't sufficient to implement
> dynamic accessibility checks in Ada 2005 or Ada 2012. He's really talking
> about an implementation short-cut that should be irrelevant to understanding
> the feature anyway. (That is, it doesn't even belong in his book.) And that
> short-cut doesn't work. Indeed, no Ada compiler has ever actually
> implemented correct accessibility checking for Ada 2005 or later. We believe
> it is possible (Steve Baird and I have worked out correct implementation
> models, but no one has tried either yet). We're supposed to be writing an
> Ada-Europe paper -- but of course that requires a trip to the Heart of
> Darkness, and neither of us has been in much a hurry to take that trip!

I'm looking forward to read this paper!

> The only thing to worry about vis-a-vis dynamic accessibility checking is
> that the object has to have a lifetime the same or longer than the access
> type.

At least this rule is easy to understand :-).

Regards,

Michael

0
Michael
12/16/2014 7:46:57 PM
<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.11.1412160940270.7909@debian...
On Tue, 16 Dec 2014, Randy Brukardt wrote:

>> Indeed, no Ada compiler has ever actually implemented correct
>> accessibility checking for Ada 2005 or later.
>
>Could you envision the ARG to drop anonymous access parameters, or at
>least severely restrict their usage, in the next language revision?
>
>If a language feature has not yet been properly implemented, you don't
>break working code by dropping this feature.

No, because what's broken isn't really relevant to the proper use of the 
feature. Typically, it just means that Program_Error isn't raised in some 
cases in which it should be -- but those cases aren't very likely to occur 
in practice anyway.

What we've actually talked about is giving up on these checks and just 
letting misuse be erroneous. Most people don't want to go there if we don't 
have to, but since we already go there for Unchecked_Deallocation, we're 
already there. Proper dangling pointer checks would be too expensive, sadly 
(especially for non-allocated objects).

And of course the compatibility cost would be significant. We might consider 
some additional restrictions (on the line of "No_Coextensions" and 
"No_Anonymous_Allocators", see H.4), but I think that is as far as we could 
go.

                                     Randy.



0
Randy
12/16/2014 8:47:25 PM
"Michael B." <michaelb@example.com> wrote in message 
news:m6q27d$l4s$1@speranza.aioe.org...
> On 12/16/14 08:45, Randy Brukardt wrote:
>> We in the ARG call discussing accessibility a "trip to the Heart of
>> Darkness", and indeed, 3.10.2 is now informally called the "Heart of
>> Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the
>> desperate or foolhardy venture there.
>
> Heart of Darkness?! When reading this part of the ARM it felt a little bit 
> weird. But I had no idea it could be *that* bad ;-).
>
>> I had heaard about the issue that John mentions in this paragraph, but I
>> never understood it (I don't think Janus/Ada does it). I've had it 
>> explained
>> to me a couple of times, and I sort of understand it, but you'd have to 
>> pay
>> me to spend an hour finding an example and writing up an appropriate
>> explanation. It's that draining - I wouldn't do it for free. Sorry.
>
> Does that mean I should give up on that issue as I will never be able to 
> understand it?

Well, if you do understand it, we need you on the ARG. :-)

>> Besides, I agree with the others that it has nothing to do with OOP. Claw
>> only uses anonymous access parameters to get the effect of in out 
>> parameters
>> in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
>> noted, it doesn't work very well. Anonymous access parameters: just say 
>> no!!
>
> How can I avoid them when they are heavily used in so many libraries?

Get better-designed libraries.

> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is 
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two 
> evils.

You could write GUIs using Claw (see www.rrsoftware.com), which surely does 
not have this mess. (Of course, I'm biased about Claw.) No bare C required. 
That's true of many other libraries as well. One thing about GUI and 
containers libraries -- much like the weather, if you don't like one, there 
are plenty of others to use.

Anonymous access parameters tends to make calls ugly (because they have to 
be filled with 'Unchecked_Access), clutter the object declarations (because 
of the need to explicitly declare them aliased), and also have what Bob Duff 
calls a "tripping hazard" -- the fact that Program_Error might be raised if 
they are passed a local object. But that depends on how they are used in the 
implementation, so no users can know whether or not it is safe to pass a 
local.

....
>> The only thing to worry about vis-a-vis dynamic accessibility checking is
>> that the object has to have a lifetime the same or longer than the access
>> type.
>
> At least this rule is easy to understand :-).

Right. It's not 100% accurate, but trust me, you don't want to figure out 
the rules to perfect accuracy. Moreover, if you don't use anonymous access 
parameters and discriminants, and don't use 'Access in generic bodies, all 
of the checking will be done at compile-time, so you can just use the old 
"if it compiles, it must be right" strategy. Which is the best way to deal 
with accessibility -- unless of course you are trying to implement it.

                            Randy.




0
Randy
12/16/2014 8:59:04 PM
On 16.12.14 21:47, Randy Brukardt wrote:
> What we've actually talked about is giving up on these checks and just
> letting misuse be erroneous. Most people don't want to go there if we don't
> have to, but since we already go there for Unchecked_Deallocation, we're
> already there. Proper dangling pointer checks would be too expensive, sadly
> (especially for non-allocated objects).

I imagine seeing future subprogram specs look like

   procedure I_Know_what_I_am_doing
      (Param : not null unchecked_access Typ);


ARGh ;-)

0
Georg
12/16/2014 9:24:11 PM
On Tuesday, December 16, 2014 8:57:50 AM UTC-5, Michael B. wrote:
>=20
> I tried to find the paper you mentioned. But the only source I found is=
=20
> the ACM website where I can buy it. Is this text somewhere publicly=20
> available?
>=20


I have a copy of the paper around, if you are that into things, but it's ce=
rtainly not a casual read, nor does it really appeal to anyone except for t=
he phony-tough or crazy-brave.  In any case, to go into a little more detai=
l, the whole model is based on the idea of comparing the relative 'depths' =
(i.e. source code nesting), but that's a messy proposition because the dept=
h is dynamic.  The relative example is as follows:

procedure Example6  is
  =20
   type T is ...;
  =20
   procedure P1(XP1 : access T) is
      type A is access T;
      Ptr: A :=3D null;
     =20
      procedure P2(XP2: access T) is
      begin
         Ptr :=3D A(XP2);
      end P2;
     =20
   begin
      P2(XP1);
   end P1;
  =20
   X : aliased T;

begin
   declare
      Y : aliased T:
    begin
      declare
         Z : aliased T;
       begin
         P1(X'Access); =20
         P1(Y'Access);
         P1(Z'Access);   -- pass or fail?
       end;
    end;
end Example6;

In this example, note that all the objects X, Y and Z are all longer lived =
than type A, which conceptually only exists for the duration that P1 is exe=
cuting, so each conversion should pass.  But also note that the "depths" of=
 the objects that P1 (and consequently, P2) is getting are becoming progres=
sively "deeper" as each declarative block gets elaborated.  The question th=
en becomes what "depths" should the conversion in P2 be checking?  If the n=
ormal block-nesting level was used (where X is 1, Y is 2, and Z is 3), then=
 Z would become evaluated as "too deep", since A would be 2 and Z would be =
3, and you would get an erroneous program error doing the conversion.

So you can tweak things to say that in these special cases, you pass the *l=
ower* of either the actual object depth or P1 itself.  So, in this case, no=
w Z will pass the dynamic check since instead of getting the depth of Z, P2=
 gets the depth of P1 (since 1<3).  Now you can nest the declarative blocks=
 a billion levels deep, and the proposed model still adheres to the LRM.

Again, it's important to stress that this is just one special case of one s=
pecial part of just one possible implementation of one special-case languag=
e feature from twenty years ago, and that none of this should weigh heavily=
 on your mind when learning or using Ada. =20

-sb


0
sbelmont700
12/16/2014 9:34:56 PM
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:

> > Besides, I agree with the others that it has nothing to do with OOP. Cl=
aw
> > only uses anonymous access parameters to get the effect of in out param=
eters
> > in functions (which isn't a problem with Ada 2012 anyway), and as Dmitr=
y
> > noted, it doesn't work very well. Anonymous access parameters: just say=
 no!!
>=20
> How can I avoid them when they are heavily used in so many libraries?
> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL=
=20
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found=20
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is=
=20
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two=
=20
> evils.

I don't see how it could be a problem if you *use* a subprogram that requir=
es an anonymous access parameter.  You can pretty much just pass in an obje=
ct of any matching named access type, or 'Access (or 'Unchecked_Access) of =
a matching object.  You don't need to create any new anonymous access types=
 in order to do so.

I'm sure Randy was being tongue-in-cheek when he said "get better libraries=
".  For one thing, you'd have to get better libraries than the libraries Ad=
a provides, because Ada defines some subprograms with anonymous access para=
meters--namely Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time=
..Timers.Timer, and Read|Write_Exception_Occurrence in Ada.Exceptions.  Also=
, the stream attribute subprograms ('Read, 'Write, etc.) all have anonymous=
 access parameters, and you have to *write* a subprogram that has an anonym=
ous access parameter in order to use it as the stream subprogram for a type=
..  Quelle horreur!  Anyway, I think you can avoid defining new subprograms =
that take anonymous access parameters (except where needed for streams, or =
for Generic_Dispatching_Constructor) and not add to the problem, but I don'=
t see any value in avoiding existing libraries.

                                -- Adam
0
Adam
12/17/2014 2:02:37 AM
On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> Right. It's not 100% accurate, but trust me, you don't want to figure out 
> the rules to perfect accuracy. Moreover, if you don't use anonymous access 
> parameters and discriminants, and don't use 'Access in generic bodies, all 
> of the checking will be done at compile-time, so you can just use the old 
> "if it compiles, it must be right" strategy. Which is the best way to deal 
> with accessibility -- unless of course you are trying to implement it.

Now you got me really worried, because I thouhgt access discriminants
were safe. It was under that assumption that I actually started to
really like them.

More specifically, the pattern I caught myself using a lot looks like
the following:

   type Preprocessed_Data (Input_Data : access Input_Data_Type) is record
      Computed_Value_1 : Type_1;
      Computed_Value_2 : Type_2;
   end record;

   procedure Private_Helper (Data : in Preprocessed_Data) is
   begin
      --  Do stuff qui Computed_Value_* and maybe also with Input_Data
   end Private_Helper;

   procedure Process (Input_Data : in out Input_Data_Type) is
      Data : Preprocessed_Data (Input_Data'Access);
   begin
      --  Initialize Data.Computed_Value_*
      Private_Helper (Data);
   end Process;

For course, it means that Input_Data is actually aliased, so it must be
of a tagged type (or maybe a limited type works too?).

That way a strong connection is maintained between the original data and
whatever is derived from it, and it gets to be handled in a single value
rather than letting the number of arguments explode when there are
several preprocessed types or steps. Though I started building such
types to use generics that expected a single type/value.

Am I doing something danegerous here?
Should I try to find another pattern to achieve the same effects?

From what I understood, here accessibility is statically known to be
fine, isn't it? Or is there a trap hidden in there?


Thanks for your thoughts,
Natasha
0
Natasha
12/17/2014 7:02:56 AM
On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:

> Now you got me really worried, because I thouhgt access discriminants
> were safe. It was under that assumption that I actually started to
> really like them.
> 
> More specifically, the pattern I caught myself using a lot looks like
> the following:
> 
>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is record

not null access?

>       Computed_Value_1 : Type_1;
>       Computed_Value_2 : Type_2;
>    end record;
> 
>    procedure Private_Helper (Data : in Preprocessed_Data) is
>    begin
>       --  Do stuff qui Computed_Value_* and maybe also with Input_Data
>    end Private_Helper;
> 
>    procedure Process (Input_Data : in out Input_Data_Type) is
>       Data : Preprocessed_Data (Input_Data'Access);
>    begin
>       --  Initialize Data.Computed_Value_*
>       Private_Helper (Data);
>    end Process;
> 
> For course, it means that Input_Data is actually aliased, so it must be
> of a tagged type (or maybe a limited type works too?).
> 
> That way a strong connection is maintained between the original data and
> whatever is derived from it, and it gets to be handled in a single value
> rather than letting the number of arguments explode when there are
> several preprocessed types or steps. Though I started building such
> types to use generics that expected a single type/value.
> 
> Am I doing something danegerous here?
> Should I try to find another pattern to achieve the same effects?

The language should. Access disciminant is a hack. The pattern should have
been:

   procedure Process (Input_Data : in out Input_Data_Type) is
      Data : Preprocessed_Data (Input_Data);

with a proper constructor "virtualizing" Input_Data_Type "discriminant" of
Preprocessed_Data.

   type Preprocessed_Data (Input_Data : Input_Data_Type) is ...;
private
   type Preprocessed_Data is ... -- No discriminant actually
   overriding
      procedure Initialize (Input_Data : Input_Data_Type);

> From what I understood, here accessibility is statically known to be
> fine, isn't it? Or is there a trap hidden in there?

AFAIK, it is safe.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
12/17/2014 8:28:41 AM
On 2014-12-17, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:
>
>> Now you got me really worried, because I thouhgt access discriminants
>> were safe. It was under that assumption that I actually started to
>> really like them.
>> 
>> More specifically, the pattern I caught myself using a lot looks like
>> the following:
>> 
>>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is record
>
> not null access?

I tought access discriminants were not allowed to be null.
Has that changed?
Or do you advise "not null access" to make it explicit?


Natasha
0
Natasha
12/17/2014 9:06:15 AM
On 12/16/14 22:34, sbelmont700@gmail.com wrote:
> I have a copy of the paper around, if you are that into things, but
> it's certainly not a casual read, nor does it really appeal to anyone
> except for the phony-tough or crazy-brave.


I would be happy if you could send me a copy. My mail address is:

mb_public <at> safe-mail <dot> net

I hope it will not cause too much damage to my mental health ;-)


> procedure Example6  is
>
>     type T is ...;
>
>     procedure P1(XP1 : access T) is
>        type A is access T;
>        Ptr: A := null;
>
>        procedure P2(XP2: access T) is
>        begin
>           Ptr := A(XP2);
>        end P2;
>
>     begin
>        P2(XP1);
>     end P1;
>
>     X : aliased T;
>
> begin
>     declare
>        Y : aliased T:
>      begin
>        declare
>           Z : aliased T;
>         begin
>           P1(X'Access);
>           P1(Y'Access);
>           P1(Z'Access);   -- pass or fail?
>         end;
>      end;
> end Example6;


> In this example, note that all the objects X, Y and Z are all longer
> lived than type A, which conceptually only exists for the duration
> that P1 is executing, so each conversion should pass.  But also note
> that the "depths" of the objects that P1 (and consequently, P2) is
> getting are becoming progressively "deeper" as each declarative block
> gets elaborated.  The question then becomes what "depths" should the
> conversion in P2 be checking?  If the normal block-nesting level was
> used (where X is 1, Y is 2, and Z is 3), then Z would become evaluated
> as "too deep", since A would be 2 and Z would be 3, and you would get
> an erroneous program error doing the conversion.
>
> So you can tweak things to say that in these special cases, you pass
> the *lower* of either the actual object depth or P1 itself.  So, in
> this case, now Z will pass the dynamic check since instead of getting
> the depth of Z, P2 gets the depth of P1 (since 1<3).  Now you can nest
> the declarative blocks a billion levels deep, and the proposed model
> still adheres to the LRM.

Ah, this is a nice example with a good explanation.
Thank you very much! Now I think I understand why this rule exists and 
how it is working.

> Again, it's important to stress that this is just one special case of
> one special part of just one possible implementation of one
> special-case language feature from twenty years ago, and that none of
> this should weigh heavily on your mind when learning or using Ada.

Does that mean that a compiler writer is allowed to implement this rule, 
but it is not strictly necessary?

I tried to compile and run your example. I replaced
"type T is ...;" by "type T is new Integer;"
and "type A is access T;" by "type A is access all T;"
to get it compiled (with Gnat 4.9 on Debian Jessie 8.0 amd64).
It runs but "P1(Z'Access);" raises Program_Error.

If I understand you correctly this is not a compiler bug and this 
optional rule was just not implemented in Gnat, right?

Regards,

Michael
0
Michael
12/17/2014 2:30:55 PM
On Wednesday, December 17, 2014 9:30:57 AM UTC-5, Michael B. wrote:
>=20
> If I understand you correctly this is not a compiler bug and this=20
> optional rule was just not implemented in Gnat, right?
>=20

It sounds very much like a compiler bug; regardless of the mechanism that t=
he compiler writer chooses to use to implement the rules of the language, i=
t must in fact implement them correctly and completely (i.e. all those conv=
ersions should pass, no matter if they use the model proposed in the paper,=
 or something else entirely).  GNAT is infamous for blowing all sorts of dy=
namic accessibility checks, many much more common than this convoluted edge=
 case, so it's not altogether shocking.  But as others have said, the rules=
 are getting so insane that its tough to even know what the correct behavio=
r ought to be, let alone whether a compiler does it (or could ever actually=
 hope to do it at all).

Hopefully someone who knows more will verify what that code should actually=
 do.

-sb


0
sbelmont700
12/17/2014 3:41:35 PM
On Wednesday, December 17, 2014 6:30:57 AM UTC-8, Michael B. wrote:

> Does that mean that a compiler writer is allowed to implement this rule, 
> but it is not strictly necessary?
> 
> I tried to compile and run your example. I replaced
> "type T is ...;" by "type T is new Integer;"
> and "type A is access T;" by "type A is access all T;"
> to get it compiled (with Gnat 4.9 on Debian Jessie 8.0 amd64).
> It runs but "P1(Z'Access);" raises Program_Error.
> 
> If I understand you correctly this is not a compiler bug and this 
> optional rule was just not implemented in Gnat, right?

I don't think there are any "optional" accessibility rules.

                               -- Adam
           

0
Adam
12/17/2014 4:03:56 PM
"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnm92al9.nrc.lithiumcat@nat.rebma.instinctive.eu...
....
> Am I doing something danegerous here?
> Should I try to find another pattern to achieve the same effects?
>
> From what I understood, here accessibility is statically known to be
> fine, isn't it? Or is there a trap hidden in there?

I think it is *supposed* to be statically fine. Whether the actual rules 
have that effect is unclear. Most likely, implementers will follow the 
intent rather than the actual rules (but since there have been a number of 
cases to the contrary, I wouldn't assume that unconditionally -- always 
check). (And no, I'm not going to try to figure this out for you, I try to 
minimize trips into this area.)

As always with accessibility, whenever we look at it in detail, someone 
finds a problem where the rules aren't quite what we want. That's why it's 
known as the "Heart of Darkness".

                                             Randy.


0
Randy
12/17/2014 10:25:03 PM
"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnm92hsh.nrc.lithiumcat@nat.rebma.instinctive.eu...
> On 2014-12-17, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:
>>
>>> Now you got me really worried, because I thouhgt access discriminants
>>> were safe. It was under that assumption that I actually started to
>>> really like them.
>>>
>>> More specifically, the pattern I caught myself using a lot looks like
>>> the following:
>>>
>>>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is 
>>> record
>>
>> not null access?
>
> I tought access discriminants were not allowed to be null.
> Has that changed?
> Or do you advise "not null access" to make it explicit?

Explicit is always better, regardless of the rules.

Ada 95 did not define null for anonymous access types, but all more recent 
versions of Ada do. The only implicit restriction against null that I 
remember in modern Ada is for dispatching anonymous access parameters. See 
3.10(13.1/2). Ahh, yes, AARM 3.10(26.c/2) says:

Inconsistences with Ada 95
Access discriminants and noncontrolling access parameters no longer exclude 
null. A program which passed null to such an access discriminant or access 
parameter and expected it to raise Constraint_Error may fail when compiled 
with Ada 2005. One hopes that there no such programs outside of the ACATS. 
(Of course, a program which actually wants to pass null will work, which is 
far more likely.)

Moral: If you're programming for Ada 2005 or later, always use a null 
exclusion when that makes sense. (It's even a good idea on controlling 
parameters, we would have preferred to require it but that would have been 
severely incompatible with Ada 95.)

                                Randy.


0
Randy
12/17/2014 10:58:10 PM
"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:eea29e4c-921a-467c-8007-80e80eda3507@googlegroups.com...
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:
....
>I'm sure Randy was being tongue-in-cheek when he said "get better 
>libraries".

Ahh, no.

....
>For one thing, you'd have to get better libraries than the libraries Ada 
>provides,
>because Ada defines some subprograms with anonymous access 
>parameters--namely
>Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer, 
>and >Read|Write_Exception_Occurrence in Ada.Exceptions. Also, the stream 
>attribute
>subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and 
>you
>have to *write* a subprogram that has an anonymous access parameter in 
>order to
>use it as the stream subprogram for a type.  Quelle horreur!

Yup. With the exception of timers, all of the others stem directly from the 
mistake of using an anonymous access for streams. And *that* stems from the 
mistake of not allowing "in out" parameters for functions (as Input is a 
function).

Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
And one should think of them as exactly that. (It's too late to fix this 
mistake, sadly.)

In the case of Timer, (a) no one ever uses this feature, and (b) I have no 
idea why this just isn't

type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;

I have no idea who has an aliased Task_Id laying around anyway. That seems 
amazingly hard to use for no value whatsoever. I suspect it was something 
else originally and it never got changed sensibly.

>Anyway, I think you can avoid defining new subprograms that take anonymous 
>access
>parameters (except where needed for streams, or for 
>Generic_Dispatching_Constructor)
>and not add to the problem, but I don't see any value in avoiding existing 
>libraries.

Well, if you could tell a-priori if "access" was used as a stand-in for "in 
out", then it would be OK. In that case, the only use of the "access" is to 
dereference it.

But it if is actually used as an access type (with the access value being 
copied somewhere), then you have trouble (with random Program_Errors and a 
need to avoid passing local objects). It's possible in Ada 2012 to write a 
precondition for this case, but of course that's not required (and surely is 
not found in existing libraries), so the possibility doesn't help much.

Since you can't tell these cases apart (and the first is never necessary in 
Ada 2012 anyway, with the possible exception of foreign conventions), it's 
best to just avoid the feature. Especially as "access" is more expensive 
than "in out" because of the dynamic accessibility checking overhead (which 
exists regardless of whether it is ever used). Libraries should reflect this 
(moreso as Ada 2012 gets adopted more).

                                Randy.


0
Randy
12/17/2014 11:18:59 PM
On 17-Dec-14 00:02, Natasha Kerensikova wrote:
> Now you got me really worried, because I thouhgt access discriminants
> were safe. It was under that assumption that I actually started to
> really like them.

Discriminants that are an access-type have exactly the scope-validity of 
the type, and therefore exhibit /exactly/ the "perfect fit" for 
accessibility.

In short: use them to your heart's content.
0
Shark8
12/18/2014 12:47:22 AM
"Randy Brukardt" <randy@rrsoftware.com> writes:

> Yup. With the exception of timers, all of the others stem directly from the 
> mistake of using an anonymous access for streams. And *that* stems from the 
> mistake of not allowing "in out" parameters for functions (as Input is a 
> function).

Yes, and *that* stems from the unfortunate fact that 'out' parameters
don't work like function results (for composites).

> Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
> And one should think of them as exactly that. (It's too late to fix this 
> mistake, sadly.)

Yes.

> In the case of Timer, (a) no one ever uses this feature, and (b) I have no 
> idea why this just isn't
>
> type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;

Because Task_Id is a private type, and unfortunately you can't have
discriminants of private type in Ada.

> But it if is actually used as an access type (with the access value being 
> copied somewhere), then you have trouble (with random Program_Errors and a 
> need to avoid passing local objects). It's possible in Ada 2012 to write a 
> precondition for this case, but of course that's not required (and surely is 
> not found in existing libraries), so the possibility doesn't help much.

Not sure what you mean.  Could you show an example of such a
precondition?

- Bob
0
Robert
12/18/2014 12:56:56 AM
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccwq5prd0n.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
....
>> In the case of Timer, (a) no one ever uses this feature, and (b) I have 
>> no
>> idea why this just isn't
>>
>> type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited 
>> private;
>
> Because Task_Id is a private type, and unfortunately you can't have
> discriminants of private type in Ada.

Ah yes, another language bug that we had to work around. I'm sure that by 
Ada 2045 discriminants will be allowed to be any type. ;-)

> But it if is actually used as an access type (with the access value being
>> copied somewhere), then you have trouble (with random Program_Errors and 
>> a
>> need to avoid passing local objects). It's possible in Ada 2012 to write 
>> a
>> precondition for this case, but of course that's not required (and surely 
>> is
>> not found in existing libraries), so the possibility doesn't help much.
>
> Not sure what you mean.  Could you show an example of such a
> precondition?

We extended membership checks to do accessibility checking in Ada 2005. (One 
of the things near the top of my ACATS priority list is to create a couple 
of tests for that feature.)

So if you have something like (stolen from Claw):

     type Any_Window_Type is access all Root_Window_Type'Class;

then you could write:

     procedure Show (Win : access Root_Window_Type; How : in 
Show_Window_Kind)
         with Pre => Win in Any_Window_Type;

and that will fail if Win is not convertable to Any_Window_Type, including 
accessibility. (See 4.5.2(30.3/4)). [I think we put this feature in in 
response to a comment/e-mail made by one Bob Duff. But it was a long time 
ago, so I might be wrong about that.]

The presence of such a precondition clearly shows that we're going to make 
an accessibility check in the body of the routine, and thus one had better 
not pass a local object. Of course if you just have:

     procedure Show (Win : access Root_Window_Type; How : in 
Show_Window_Kind);

you don't know that there isn't any conversion. Indeed, I don't know of any 
way to declare that no conversion happens (you can't really write that there 
are no restrictions). I suppose Pre => True sort of has that effect, if it's 
really meant and not just a short-hand for I-dunno!

Of course, the actual Claw specification is:
     procedure Show (Win : in Root_Window_Type; How : in Show_Window_Kind);
and we use 'Unchecked_Access and finalization to ensure that there's no 
dangling pointer problems for the conversion. Which is better still, IMHO 
(as no restrictions are needed).

                                            Randy.




0
Randy
12/18/2014 1:17:23 AM
On 17-Dec-14 18:17, Randy Brukardt wrote:
> Ah yes, another language bug that we had to work around. I'm sure that by
> Ada 2045 discriminants will be allowed to be any type.

Hm, I wonder about discriminated enumerations... ;)
0
Shark8
12/18/2014 5:29:49 AM
On Wed, 17 Dec 2014 17:18:59 -0600, Randy Brukardt wrote:

> Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
> And one should think of them as exactly that. (It's too late to fix this 
> mistake, sadly.)

But stream attributes are hard-wired anyway. Why not to add ones with the
in-out stream parameter? One one can be overridden (and so defines
another), any can be used? It is similar to how "=" and "/=" are treated.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
Dmitry
12/18/2014 8:27:26 AM
On 12/17/14 17:03, Adam Beneschan wrote:
> I don't think there are any "optional" accessibility rules.

Do you think it's a compiler bug?
0
Michael
12/18/2014 4:07:46 PM
On 12/17/14 16:41, sbelmont700@gmail.com wrote:
> It sounds very much like a compiler bug; regardless of the mechanism
> that the compiler writer chooses to use to implement the rules of the
> language, it must in fact implement them correctly and completely
> (i.e. all those conversions should pass, no matter if they use the
> model proposed in the paper, or something else entirely).

That makes sense. So it seems my misunderstanding came from too much 
trust in a compiler...
0
Michael
12/18/2014 5:48:32 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:vxaluu2b5jkb.10f4p234jkqzz.dlg@40tude.net...
> On Wed, 17 Dec 2014 17:18:59 -0600, Randy Brukardt wrote:
>
>> Ergo, in Ada 2012 you would write those as "in out 
>> Root_Stream_Type'Class".
>> And one should think of them as exactly that. (It's too late to fix this
>> mistake, sadly.)
>
> But stream attributes are hard-wired anyway. Why not to add ones with the
> in-out stream parameter? One one can be overridden (and so defines
> another), any can be used? It is similar to how "=" and "/=" are treated.

Might work, but it would be pretty messy and unclear (to most) that it would 
buy enough for the pain. Probably better to just plan on that in Ada++. :-)

                                 Randy.


0
Randy
12/18/2014 9:20:15 PM
I said:
....
> We extended membership checks to do accessibility checking in Ada 2005.

Actually, that was in Ada 2012, which I could have found out by reading the 
AARM at the bottom of 4.5.2 more closely. Sorry about the confusion.

                                         Randy.


0
Randy
12/18/2014 11:12:16 PM
Thank you to all of you for your helpful answers!
This whole accessibility thing is now much clearer to me.

Regards,

Michael

0
Michael
12/19/2014 12:16:35 PM
Reply:

Similar Artilces:

Accessing Access
Hello, what would be a good module for accessing data contained in a MS Access database file? Are there any examples of doing this that you know of? In article <nn1Ah.2617$2%1.2205@trndny02>, <QoS@domain.invalid.com> wrote: > >Hello, what would be a good module for accessing data contained in >a MS Access database file? Are there any examples of doing this >that you know of? Depends what kind of platform you can use. If you are under Windows, DBD::ODBC will work wonders. If you `bridge' Windows <-> Unix, you can set up a DBI::ProxyServer on a windows...

access to Access
We use MS access 2000 at work and few people know how to work it including me. We are using it on a network and more than one person is trying to access it at once. Needless to say this isn't working as one has to log out first before another can enter data. Is there an easy way around this? Or a complicated way, actually I'll take anyway. Thanks Mike We have just started this database so any changes would be better done sooner. Mike Kelliher wrote: > We use MS access 2000 at work and few people know how to work it > including me. > We are using it on a network and mo...

access to Access
I've been reading some old posts that talk of an inability to connect to an Access database with RB. Is that (still) true? If so, that would be a show stipper for us. Thanks for any insight, dave In article <1187719558.603002.257260@q3g2000prf.googlegroups.com>, Dave <davegp2@msn.com> wrote: > I've been reading some old posts that talk of an inability to connect > to an Access database with RB. Is that (still) true? If so, that > would be a show stipper for us. I've never tried it, but I think you should be able to access Access via ...

Accessing access
Can anyone help me please? This has been driving me nuts for ages. I want to use vb 6.0 to control data in a database (an access database). I've looked at tutorial all over the net but I don't want to use a data grid or anything like that because I want to control the database, not see it. So far, from one tutorial I've managed to get something on the lines of this ****************************************** dim db as Database Set db = OpenDatabase("E:\BT.mdb") dim rspeople as recordset set rspeople = db.openrecordset("people") **************...

Accessing webservice from access
Hi Is it possible to call a web service that returns a dataset, from access? Could I please have an example of how to call such a service from access? Thanks Regards "John" <john@nospam.infovis.co.uk> wrote in message news:40d73cf3$0$287$cc9e4d1f@news-text.dial.pipex.com... > Hi > > Is it possible to call a web service that returns a dataset, from access? > Could I please have an example of how to call such a service from access? > > Thanks > > Regards I don't know if there's an easier way but you can use the MSXML object. I suggest you do...

Accessing... accessing... fascinating
The AIX has fallen... -- Reply to ohland@charter.net ...

Spawning Access from Access
Hello, Is it possible to spawn an Access program from another Access program with out going to a batch file or something? I would like to have an Access main menu and bring up a different front end Access program depending on the menu selection. I'm using Access 2000. Thanks, Hank Reed On 27 Dec 2004 05:26:34 -0800, "Hank" <hankrunner@aol.com> wrote: Sure. You can use Automation like this: dim o as new Access.Application o.visible=true o.OpenCurrentDatabase "c:\two.mdb", False -Tom. >Hello, >Is it possible to spawn an Access program from another Acc...

ACCESS accessibility from a C++ process launched from an ACCESS form
Here is my problem. From an ACCESS form, I run a C++ process reaching the same database in read/write mode via the ODBC driver. An error occurs: " The database has been placed by an unknown user in a state preventing it from being opened either locked. SQLSetConnectAttr failure of the pilot " (Nota : translated approximatively from the french error message). However, if I have used an another form before (eg. to modify a table), or if I have modified myself a record of any table, there is no problem. It seems that the database is in a state " read-only " by default until th...

Accessing Notes from Access
Hello All, We have been charged with extracting some information from a notes database, into access or excel. We don't own any lotus products at all. We've tried installing NotesSQL odbc driver, which appears to install just fine, but it doesn't add any odbc driver to the listing, and when I run the admin tool it tells me that we don't have any appropriate version of notes on the machine. The system prereq stated we needed one of the lotus apps. So, I assume that we won't have access to the notessql driver unless we get a copy of notes or domino. The...

access to Access #2
I've been reading some old posts that talk of an inability to connect to an Access database with RB. Is that (still) true? If so, that would be a show stipper for us. Thanks for any insight, dave ...

Access Controls in Access
How on access can you set access controls to your users? If they log in with one username and password they can just read information and if they log in with another username and password they can read and write? I have no idea how to do this, is it even possible?? Thank you Try playing with the access security tool, you can add users, groups, passwords, read/write allowances etc. to your database using that. Its under the 'Tools' menu of Access. Brian wrote: > Try playing with the access security tool, you can add users, groups, > passwords, read/write allowances etc. to you...

Access to Excel to Access
I have a form with two text boxes, text1 and text2. What I need is a button that exports each text box to a specific cell in an excel file, the excel file needs to be refreshed/updated so a calculation will run and the cell containing the calculation result is passed back to a third text box on the form in access. Ideas? fonzie wrote: > I have a form with two text boxes, text1 and text2. What I need is a > button that exports each text box to a specific cell in an excel file, > the excel file needs to be refreshed/updated so a calculation will run > and the cell containing th...

accessing ms access via ODBC without Microsoft Access
Hi, If I have a computer without Microsoft Access installed but with an ODBC connection to a .mdb file - can I still access the 'database' via ODBC? thanks Tim <timasmith@hotmail.com> wrote in message news:1145206985.433826.106120@i40g2000cwc.googlegroups.com... > Hi, > > If I have a computer without Microsoft Access installed but with an > ODBC connection to a .mdb file - can I still access the 'database' via > ODBC? Yes, provided you are running a program prepared in a language that supports ODBC and have installed an ODBC driver on that user'...

No access to .dbf files in access 97 after installing access 2003
Hello, I need to maintain an access97 database that is linked to dbf's, but after having installed access 2003, when I try to link a .dbf file to an access97 database, I only have access and odbc when the dialog box to choose the external table comes up. I tried going to control panel and change my office 97 setup. When I go to the data access option, dbf is grayed out with a checkmark in it and it states that dbf access is already installed. Yet, I don't have access to that option when trying to link my dbf table to the access97 database. Any way to get that option back on? Than...

Web resources about - Access parameters and accessibility - comp.lang.ada

Accessibility - Wikipedia, the free encyclopedia
For the related design concept, see Universal design . For the logical notion, see Accessibility relation . For accessibility on the internet, ...

Accessibility - Wikipedia, the free encyclopedia
For the related design concept, see Universal design . For the logical notion, see Accessibility relation . For accessibility on the internet, ...

Accessibility - Wikipedia, the free encyclopedia
For the related design concept, see Universal design . For the logical notion, see Accessibility relation . For accessibility on the internet, ...

Accessibility - Wikipedia, the free encyclopedia
For the related design concept, see Universal design . For the logical notion, see Accessibility relation . For accessibility on the internet, ...

Facebook Improves Accessibility Of Mobile Apps
Facebook is a wonderfully picturesque site , and the company wants those who are visually impaired to be able to experience that, as well. The ...

Designing for Accessibility: Q&A with Jeff Wieland - Facebook
Facebook Design hat eine Notiz mit dem Titel Designing for Accessibility: Q&A with Jeff Wieland geschrieben. Du kannst den vollständigen Text ...

Application Accessibility Improves in Facebook Redesign
As announced earlier today, Facebook this evening released updates to the new site design that make it easier for users to find and bookmark ...

Accessibility Oz (@accessibilityoz) on Twitter
Accessibility Oz (@accessibilityoz) on Twitter

iOS 7 Accessibility Improvements for Switch Users
Christopher Hills explains the news-to-me accessibility improvements in iOS 7 for users of switches (like this one, from Tecla ).

Government: Sydney improving accessibility with new 'wayfinding' network
A new signage system will make it easier to get around the city.

Resources last updated: 1/26/2016 5:28:14 AM