Stuart McLachlan
stuart at lexacorp.com.pg
Sun May 15 18:01:01 CDT 2011
Never seen it done that way before (wrapping the associated application in a RunDLL).
I just Declare ShellExecute in a "General Functions" module:
Public Declare Function ShellExecute Lib "SHELL32.DLL" Alias "ShellExecuteA" (ByVal
hwnd As Long, ByVal lpOperation As String, _
ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal
nShowCmd As Long) As Long
and then use:
If (MaterialName > "") Then
If (Dir$(BEDir() & "LibMat\" & MaterialName) > "") Then
ShellExecute Application.hWndAccessApp, "Open", BEDir() _
& "LibMat\" & MaterialName, "", "", vbNormalFocus
Else
MsgBox MaterialName & " is missing from the LibMat directory!",,strAppTitle
MaterialName = ""
DoCmd.RunCommand acCmdSaveRecord
End If
End If
--
Stuart
On 15 May 2011 at 15:16, Rocky Smolin wrote:
> I use the following to open the file:
>
> If IsNull(Me.txtPicture) Then Exit Sub
> Shell "RunDLL32.EXE shell32.dll,ShellExec_RunDLL " &
> Me.txtPicture,
> vbMaximizedFocus
>
> Where Me.txtPicture contains the path and file name of the target.
>
> The file is opened by the application to which the file extension is
> associated. So if there's a pdf in txtPicture it opens with Reader,
> .doc file opens with Word, etc. I suppose you could stash the path
> and file name of an .mdb file and it would open in Access.
>
> Of course, if they move the file, the link is broken. I suppose I
> should put a FIleExists check before the Shell and give a freindly
> message if the file's not there.
>
> Rocky
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darrell
> Burns Sent: Sunday, May 15, 2011 2:56 PM To: 'Access Developers
> discussion and problem solving' Subject: Re: [AccessD] Should I use
> Attachments?
>
> Jim & Rocky,
>
> What I like about the Attachment object is that:
> 1. it handles multiple files;
> 2. the user only has to dbl-click, select a file, and open; 3. since
> the images are stored in the DB it doesn't matter if the files are
> moved, renamed, or deleted. Have you guys (or anybody else) developed
> a way to mimic that functionality through links?
>
> Re: Jim's point about the the image being retrieved as the user moves
> thru the records...does ACE actually retrieve the image when the
> record becomes current? It appears that only the file count is
> displayed and the image isn't retrieved til the user dbl-clicks. Am I
> wrong?
>
> -DB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim
> Lawrence Sent: Sunday, May 15, 2011 12:30 PM To: 'Access Developers
> discussion and problem solving' Subject: Re: [AccessD] Should I use
> Attachments?
>
> We went through this issue many times, from MS Access to Oracle and MS
> SQL databases and keeping the images external is always faster.
> Sometimes we had to store the images internal to the database but
> then, when working in Oracle forms, a button had to be added to
> initiate the image loading...if someone just flitted from record to
> record the impact of an image being retrieved from the actual database
> was show stopper...and this would impact every user on the system.
>
> My vote is to store them external and enjoy the performance.
>
> Jim
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky
> Smolin Sent: Sunday, May 15, 2011 8:50 AM To: 'Access Developers
> discussion and problem solving' Subject: Re: [AccessD] Should I use
> Attachments?
>
> Even inside the database don't you need some way to identify the
> picture - a title or caption? So renaming the jpgs is one way to do
> that and so the combo box to select the picture has those descriptive
> file names. Or in the table where you store the path and file name of
> the picture you let the user enter a short description which shows in
> the combo box. Either way the photos stay outside the db. If you
> store them in the db, the photos will still be stored outside the db
> somewhere. If they exist in two places that opens up possibilities of
> having the one set not be the same as the other set.
>
> Still voting for keeping them outside.
>
> However, I am interested in whether or not a graphic file can now be
> stored in a db without bloating it. Please let us know what your
> experiments reveal.
>
> Rocky
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller Sent: Sunday, May 15, 2011 8:16 AM To: Access Developers
> discussion and problem solving Subject: Re: [AccessD] Should I use
> Attachments?
>
> I've been toying with this new feature, which is basically a binary
> data type which a built-in compressor/decompressor. A client and I are
> experimenting with it, for one basic reason: a given record might have
> associated with it anywhere from 2 to 60 photos. Having that many
> photos living in some directory somewhere, especially given their
> arbitrary names, can quickly become quite a hassle. On the other hand,
> simply specifying the path to a given client's photos seems workable.
> So I don't yet know which method we'll choose.
>
> A.
>
> On Sun, May 15, 2011 at 7:25 AM, Jim Dettman <jimdettman at verizon.net>
> wrote:
>
> >
> > I'm not sure what you mean by "not backward-compatible". It's a
> > new
> > feature and did not exist in prior versions, so yes, it would not be
> > available in JET (it's an ACE only feature).
> >
> > As far as performance, I have not heard anything in that regard.
> > It's not the same animal as an OLE field; there is no OLE wrapper
> > around
> the object.
> > And the data is compressed to boot. So bloating DB's is a thing of
> > the past.
> >
> > However because of that, you just can't pull the raw data out and
> > move it or use it in some other way. Also, you still must contend
> > with the ACE DB limit of 2GB.
> >
> > Given all that, I would still do it the traditional way as Rocky
> > said; store a path in the DB and keep everything outside of the DB.
> >
> > Jim.
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darrell
> > Burns Sent: Saturday, May 14, 2011 08:33 PM To: 'Access Developers
> > discussion and problem solving' Subject: [AccessD] Should I use
> > Attachments?
> >
> > New subject: my client wants to link PDF documents to records in an
> > Asset table in an A2007 app. The attachment data type is perfect for
> > what I want to do, but I've heard bad things about it. I know one
> > caveat is that it's not backward-compatible. I've also heard that
> > it's a performance drag. (I tried using OLE fields in A2000 a few
> > years ago and quickly abandoned that approach). The Asset table
> > would range from a few hundred to a couple thousand records per
> > client. I'll be deploying
> the app as a runtime.
> >
> > I'd be interested in hearing the pros & cons of attachments.
> >
> > Thanx,
> > DB
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>