Help with some VB Code

[colemanj4]

Here is what I have so far, it loops while the PW is incorrect, or
until cancel is selected. I want it to lock the tables for adds,
deletes, and edits when cancel is selected, and if the PW is correct.

I want this to run when the DB is opened, I would also like the text
box to be starred (*) out when text is input.

Thanks for your help.

=============== ===============
Dim Show_Box As Boolean
Dim Response As String

' Set the Show_Dialog variable to True.
Show_Box = True
InputBox
' Begin While loop.
While Show_Box = True

' Show the input box.
Response = InputBox("Enter the Password to Unlock Read-Only
Mode.", _
"Read-Only Unlocking")
' See if Cancel was pressed.
If Response = "" Then

' If Cancel was pressed,
' break out of the loop.
Show_Box = False
Else
' Test Entry to find out if it is the correct password.
If "safety" = Response = True Then
'Application.Cl oseCurrentDatab ase
'Application.DB Engine.OpenData base "P:\ACTION REGISTER
\TESTERIncidet Action Register Database.mdb", , True
'Application.Op enCurrentDataba se "P:\ACTION REGISTER
\TESTERIncidet Action Register Database.mdb", False
'Access.AcOpenD ataMode.acReadO nly
Show_Box = False
Else
' If the entry was wrong, show an error message.
MsgBox "Wrong Password, Try again."
End If
End If
' End the While loop.
Wend
=============== =============== =============== =

[Rich P]

Hello,

The functionality you are trying to achieve with your code is not
supported in VBA because it requires a multithreaded environment which
would involve programming in an Object Oriented Programming platform
(OOP -- C#, VB.Net, Java...). VBA is not Object Oriented -- it is
Interpreted. The VBA compiler interprets the code as it runs thus not
requiring to compile the code into an exe which makes programming and
debugging as easy as can be. The limitation of Interpreted programming
code is that you can't perform OOP operations. It is either one or the
other. For the functionality you desire -- I would try VB.Net -- it is
the easiest OOP language to use.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Albert D. Kallal]

"Rich P" <rp*****@aol.co mwrote in message
news:12******** *****@news.news feeds.com...

Hello,

The functionality you are trying to achieve with your code is not
supported in VBA because it requires a multithreaded environment

No, the simple code posted does not need threading. The looping is ONLY
there for re-prompting the user, not the requiremnt to span a new thread.

which
would involve programming in an Object Oriented Programming platform

No, opp and threading are separate issues. The idea, concpet and
implementation of a threaded language does not require that it be an object
oriented platform at all. The idea of having threaded code does not require
you to have a opp lanaguge.

(OOP -- C#, VB.Net, Java...). VBA is not Object Oriented -- it is
Interpreted.

I hate to burst your bubble but c#, and the .net actually now use a runtime
p-code system, and is in fact compiled down into a intermediate language
that is interpreted by the CLR (common language runtime). So in this case
C#, vb.net, and VBA actually are now all compiled to an intermediate
language, or what is called a p-code system. What this means is none of
these languages actually now compile down to into true .exe files that the
intel Processor can consume. This means that your file extension of .exe, or
mdb, or whatever you choose is in fact a moot point at this point in time
now.

It is interesting that us VBA developers for years and years have been using
a p-code interpreted system, and now both c# and vb.net use a similar
architecture.

The VBA compiler interprets the code as it runs thus not
requiring to compile the code into an exe which makes programming and
debugging as easy as can be.

Once again this is complete wrong. In fact debugging systems tend to work
better when you have an intermediate p-code language. While the dot net
compilers appear to produce a .exe file, this is actually not a true
compiled file, and is NOT a native executable file. In fact the.net
debugging systems use the p-code intermediate language to their benefit, and
not their detriment as you're suggesting.

VBA does have a compiler, and it does compile it down to a p-code lanague
that is then interpreted by runtime system. So, for all of the syntax error
checking, compiling, and removal of comments from the source code, this
process is much the same in VBA as it is now in .net.

The resulting compiled file in vb.net, or in ms-access results in a p-code
(intermediate language) that then gets executed an runtime system

.. c#, and vb.net (or any other language you use that converts into the
common runtime language) STILL requires you have the.net library or runtime
system installed to interpret that code. It is not natively compiled, and
therefore this also explains why you can do x-copy development in vb.net (or
in ms-access) after you've installed the appropriate libraries that can
interpret the code that gets created by these systems.

I should point out that c++, or the even the last version of visual basic
6.0 did have a native compiler, and these two systems could in fact produce
true .exe files that could be interpreted by the Intel processor direclty
(this is TRUE native .exe's now). These resulting files of course did
require access to the windows api, but there was not an intermediate
interpreter (p-code) system like you have with .net.

The limitation of Interpreted programming
code is that you can't perform OOP operations.

Once again this is wrong, because .net is *like* an interpreted language.
Java is considered a oop language, and it does not produce native
executables in most implementations either Once you've compiled to the
p-code system, then the idea here is that supposedly your code is platform
more portable. As long as you write a p-code interpreter for that platform,
all of your code should work.

I should point out this is also why it for example you can use visual studio
to produce .net code for the mobile edition of windows (which by the way,
does not have an Intel compatible processor), or the XNA for the xbox.

It is either one or the
other.

No, it is not one choice or the other when you choose an interpreted versus
that of a compiled language. OOP operations are not exclusive to compiled
languages only.

As I pointed out the .net system is in fact interpreted language system. I
should point of course that the CLR has its own compiler that is independent
of what language you program in. The CLR interpreter does in fact have a JIT
(just in time compiler) that'll eventually take that p-code and compiles it
into the native language of your machine (in this case the Intel processor),
So I will admit that how the CLR functions is not a true p-code architecture
in the classic sense of Java, or VBA.

I'm open to being corrected on this architecture issue, but it is my
assumption that your .exe files created by the .net library in is fact a CLR
p-code .exe, and is not a native true compiled language until the JIT gets
its hands on this .exe file. You can however pre compiled.net applications
using the ngen utility.

The issue of having a full opp language, or having a language that supports
threading, has no relationship to the fact if the language is a native
compiled language, or a p-code interpreted language at all.

**Both** both of those types of languages can well implement opp features,
and also that of threading.

I should point out the MS access does allow you to create and build your own
class objects. However, the vba in access is not considered a full opp
language because it's missing features like inheritance, and a number of
other things what would give it a full oop badge.

You can read my article on building and using class objects in MS access
here:
http://www.members.shaw.ca/AlbertKal.../WhyClass.html

Keep in mind that MS access shares the same compiler as vb 6.0 but simply
does not allow us to produce a native.exe like vb 6.0 did (vb 6 allowed the
creation of both native .exe executables, or the choice of using p-code --
Once again an issue that's been dependent of oop, or threading).

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com

[colemanj4]

On May 5, 3:07*pm, colemanj4 <colema...@gmai l.comwrote:

Here is what I have so far, it loops while the PW is incorrect, or
until cancel is selected. I want it to lock the tables for adds,
deletes, and edits when cancel is selected, and if the PW is correct.

I want this to run when the DB is opened, I would also like the text
box to be starred (*) out when text is input.

Thanks for your help.

=============== ===============
*Dim Show_Box As Boolean
* * Dim Response As String

* * ' Set the Show_Dialog variable to True.
* * Show_Box = True
InputBox
* * ' Begin While loop.
* * While Show_Box = True

* * * * ' Show the input box.
* * * * Response = InputBox("Enter the Password to Unlock Read-Only
Mode.", _
* * * * * * "Read-Only Unlocking")
* * * * ' See if Cancel was pressed.
* * * * If Response = "" Then

* * * * * * ' If Cancel was pressed,
* * * * * * ' break out of the loop.
* * * * * * Show_Box = False

* * * * Else
* * * * * * ' Test Entry to find out if it is the correct password.
* * * * * * If "safety" = Response = True Then
* * * * * * * * 'Application.Cl oseCurrentDatab ase
* * * * * * * * 'Application.DB Engine.OpenData base "P:\ACTION REGISTER
\TESTERIncidet Action Register Database.mdb", , True
* * * * * * * * 'Application.Op enCurrentDataba se "P:\ACTION REGISTER
\TESTERIncidet Action Register Database.mdb", False
* * * * * * * * 'Access.AcOpenD ataMode.acReadO nly
* * * * * * * * Show_Box = False
* * * * * * Else
* * * * * * * * ' If the entry was wrong, show an error message.
* * * * * * * * MsgBox "Wrong Password, Try again."
* * * * * * End If
* * * * End If
* * * ' End the While loop.
* * * Wend
=============== =============== =============== =

OK, since what I want to do doesn't seem possible, is there a way I
could set the current user to user level access instead of admin? I
don't want ot get into doing all of the security wizard access has, as
I have tried it multiple times and it is not working. I believe that
is because of the way my corporate IT has the permissions set up for
the whole network, and they are a pain to get involved with.

So... say doej is the user, he opens up the DB, and is asked for a
password, he hits cancel and I then want to delegate him to the "User
group" which only has readonly access. Can I do this with my VBA
code?

Thanks

[Element]

Excellent response, Albert. I can't think of anything to add except a
resounding expression of agreement.
On May 6, 2:00*am, "Albert D. Kallal" <PleaseNOOOsPAM [e-mail] >
wrote:

"Rich P" <[e-mail] mwrote in message
I hate to burst your bubble but c#...

[Tom van Stiphout]

On Tue, 06 May 2008 06:00:43 GMT, "Albert D. Kallal"
<Pl************ *******@msn.com wrote:
In fact, you *can* do multithreading with VBA, same as with VB6. For
example see here: http://www.freevbcode.com/ShowCode.Asp?ID=1287
and heed that warning not to do it unless you are an expert
programmer!

-Tom.

>"Rich P" <rp*****@aol.co mwrote in message
news:12******* ******@news.new sfeeds.com...

>Hello,

The functionality you are trying to achieve with your code is not
supported in VBA because it requires a multithreaded environment

No, the simple code posted does not need threading. The looping is ONLY
there for re-prompting the user, not the requiremnt to span a new thread.

>which
would involve programming in an Object Oriented Programming platform

No, opp and threading are separate issues. The idea, concpet and
implementati on of a threaded language does not require that it be an object
oriented platform at all. The idea of having threaded code does not require
you to have a opp lanaguge.

>(OOP -- C#, VB.Net, Java...). VBA is not Object Oriented -- it is
Interpreted.

<clip>

[Rich P]

I have writtens lots of multi threaded programs. The only way you can
do it in VBA is like this:

"It can't be done!"

I have been posting in this newsgroup for several years. I have
probably not been on planet earth as long as a lot of you, but I have
taken the coding thing a little bit further. If what I say was not true
and correct, I would have disappeared a long time ago - from attrition -
as in no one would need my services. You can't do multi threading in
VBA - I have tried. The closest I came was to create to separate exe's
in VB6 where one exe monitored the operations of the other. But that is
not VBA, and that was in the previous century.

It is one thing to be an Access coder, and if that is the extent of your
horizons, fine. But for those people who need functionality that is
either not provided in this environment - or not provided easily - it is
time to step up to something a little more sophisticated. My goal is to
share how to achieve desired results with as little spaghetti code as
possible. If an operation requires tons of spaghettie code (API code,
etc) then it is time to start investigating other technologies.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Rich P]

Silly me! I am tooting my horn about how VBA doesn't support
multithreading and that you can only do it in OOP. I forgot to mention
that multithreading requires the use of delegates - here is some sample
code of a program I wrote which does something similar to what this post
is about - being able to control the execution of an operation -
start/stop:
Public Delegate Sub StartSlideShowD elegate()
Private Delegate Sub ShowPicsDelegat e(ByVal PicCount As
Integer, ByVal str2 As String)
...

btnStopStart.Te xt = "Stop SlideShow"
btnSinglePicBac k.Enabled = False
btnSinglePicFwd .Enabled = False
bRunPics = True
Dim dlgt As StartSlideShowD elegate = New
StartSlideShowD elegate(Address Of StartLoadSlideS how)
Dim state As Integer = 0
Dim ar As IAsyncResult = dlgt.BeginInvok e(New AsyncCallback
(AddressOf DoneCallback), state)
...

Try
If Me.InvokeRequir ed Then
' if operating on a thread, invoke a delegate
' on the UI thread.
Dim omd As ShowPicsDelegat e = New ShowPicsDelegat e
(AddressOf ShowPics)
Dim arx As IAsyncResult = Me.BeginInvoke( omd, New
Object() {PicCount, str2})
Me.EndInvoke(ar x)
Return
End If
...

--you can't do this in VBA. You can only do this in OOP.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Albert D. Kallal]

"Rich P" <rp*****@aol.co mwrote in message
news:12******** ******@news.new sfeeds.com...

>I have writtens lots of multi threaded programs. The only way you can
do it in VBA is like this:

"It can't be done!"

I for the most part 100% agree with the above.

If what I say was not true
and correct, I would have disappeared a long time ago - from attrition -

Your claim about VBA and threading is 100% correct. however, you claim of to
quote:

>The functionality you are trying to achieve with your code is not

supported in VBA because it requires a multithreaded environment which
would involve programming in an Object Oriented Programming platform

You DO NOT need to adopt a OOP platform to get threading. Without question
*most* modern development systems that supprot oop *useally* also support
threading, but, your above claim says that you **have** to use a OOP system
to get multithread enviroment is wrong. I was simply pointing out that these
are two mutually exclusive issues, and are not related to each other. Once
again, you do not necessarily have to adopt a oop language to get
multithreading capability.

>The limitation of Interpreted programming

code is that you can't perform OOP operations.

Once again I said the above is incorrect, and there are many interpreted
languages is today that are full oop. And, I pointed out that in fact the
..net environment relies on a p-code runtime system, very similar to that of
the vba. (and I believe on windows mobile, and also the XNA system for xbox,
there is no JIT either).

I was never questioning you're correct suggestion that threading in VBA is
silly, and the wrong tool and one is barking up the wrong tree to attempt
threading in VBA. Once again, I wholeheartedly agree with you on this issue.
It is silly and simply not the realm of VBA to write and build threaded
applications.

I should further point out that if I'm reading the original poster's
question correctly, he does not need threading as a solution anyway...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com

[Albert D. Kallal]

Actually, I have to run right now...but, let me take a look at this later
tonight....

I do think something can be cooked up here.....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com