"Michael Baytalsky" <mike@contextsoft.com> wrote in message
news:9144734B-DE01-4BC3-AD2C-E4A8D5530872@news.elevatesoft.com...
>
>> When a user wants to edit a BLOB'd document, I save the blob to a file
>> with the appropriate file name in a temporary location, then start a new
>> process to 'edit' or 'open' that document, which should start the
>> appropriate application.
>> I can monitor when that process ends to know to read the document back
>> into the BLOB.
> What if it doesn't end after closing the document (say you open another
> document in same process)?

Yes, I assumed that could happen. What I was thinking was that if they did
open another document, my document would still be there in the temporary
location, so I could compare a timestamp to see if it was changed and just
inform the user when my program ends, "application was editing XXXX using
xxxx and xxxx is still active. Accept changes and close application? y/n" or
something similar.

> inform the user when my program ends, "application was editing XXXX using
> xxxx and xxxx is still active. Accept changes and close application? y/n" or
> something similar.
The file maybe locked for reading, not properly saved, etc. You may
load corrupted file over a perfectly valid file and get killed by users



Michael

"Michael Baytalsky" <mike@contextsoft.com> wrote in message
news:19E63A21-D97A-4DAF-91E5-DCC0802BE4B3@news.elevatesoft.com...
>> inform the user when my program ends, "application was editing XXXX using
>> xxxx and xxxx is still active. Accept changes and close application? y/n"
>> or something similar.

> The file maybe locked for reading, not properly saved, etc. You may
> load corrupted file over a perfectly valid file and get killed by users
>

How about "Program is closing without updating these files: x,y,z If you
want to have updates applied, please close those applications."

I would have to do something similar even using OLE objects, right? I mean
they could try to close the application without closing the document editor
first or updating the document.

And if I used OLE objects, I would have to be prepared for all files types
that could be added.

I played around with the TOleContainer and with CreateOleObject() a little
today, but didn't know how to setup an event handler for when the items were
updated. I just found a bunch of stuff on delphi.about.com I am going to
read through.

Thanks for letting me bounce some ideas.

-Johnnie

> I would have to do something similar even using OLE objects, right? I mean
> they could try to close the application without closing the document editor
> first or updating the document.
Not really. In OLE you deal with objects, not files, so when you do
SaveAsDocument you guarantee, that the file you're saving it to, is
not corrupt (unless a problem occurs with OLE server).

> And if I used OLE objects, I would have to be prepared for all files types
> that could be added.
How's so? No, you don't have to know anything about your documents, as long
as each one is associated with OLE server. Since your working with BLOB
always begins and ends with saving/loading from file, you can actually
implement both models and see which works best. I'd say it's the opposite -
if you DON'T use Ole, then be prepared to customize editor for each file
type.

> I played around with the TOleContainer and with CreateOleObject() a little
> today, but didn't know how to setup an event handler for when the items were
> updated.
There's no event handler. You might want to look into Changed dynamic method
to see how container is notified about the document being changed. You can
inherit from TOleContainer and override Changed to provide yourself with
call back, although, I don't see why you'd need that. You have a container
and rest is up to your user. Consider that container is like a TMemo.
You don't care what user does to its content (and where it is stored), but
when he clicks OK you read from TMemo if it has changed and save to blob.
You rarely need to trap OnChange event of TMemo. If your user wants to close the
application or move on to the next document/record, *then* you check container's
status and do something about saving current document if it
has been modified, just like you would with TMemo. Another small advantage
of container is that you don't rely on disk file to be there for a long
time. You save to disk only to load into container and vice versa, so when
a user edits the document he is aware that the document is actually
not stored on disk and is from your program (you application's name will
be shown in Word's caption).

Those are just my thoughts. I'm not advising you in favor of either
approach - you should certainly implement the one you like and understand
best. The way I'd do it, I'd implement both approaches and leave it
up to user. By default, it would try to invoke using Ole. User then may
override this for each file type to invoke another application instead
by supplying command line with %1 replaced by file name. This is particularly
useful for images, because default Old server may not be a good choice of
viewer. If you're implementing a serious application, where it is important
that users will be able to work conveniently with the wide variety of
documents, then this may be the best option.


Michael

Roy,

> What happens if they open a BLOB'd document in Word, whilst in there open
> 3 other documents and never close the process, or if Word is already
running......
You may use the sinks and subscribe for event when your document
saved/closed in MS Word.
See the samples and articles at http://www.techvanguards.com/com

--
With best regards, Mike Shkolnik
E-mail: mshkolnik@scalabium.com
WEB: http://www.scalabium.com

Johnnie,

If you are not locked into using a BLOB, you could try an
alternate approach. I just store information about documents
in a database and store copies in a dedicated \documents
folder under the database. I maintain a table of documents
with a structure similar to this:

SerialNumber: TLargeIntField (unique ID)
ParentSerialNumber: TLargeIntField (record attached to)
Description: TStringField
Filename: TStringField
Comments: TMemoField

with 3 buttons on the form:

Load
Open
Save As

Load browses the disk for a file and if selected, makes a
copy in the databasename\documents subfolder (warns of
duplicates/overwrites).

Open just uses ShellExecute(Handle, 'open'...) and lets the
OS do the work.

Save As just allows the user to make a copy of the document
anywhere on the disk. Warns of overwrites and if you are
saving it in the databasename\documents folder.

The benefits for me are:

Very easy to code
Very easy to explain to end users
Works with any file type registered with the OS (word
processing, spreadsheets, photos, movies, etc)
One document can be attached to multiple records, so no
wasted space.

Sean



Johnnie Norsworthy wrote:
> I just thought about a more universal approach that might work for my
> application.
>
> When a user wants to edit a BLOB'd document, I save the blob to a file with
> the appropriate file name in a temporary location, then start a new process
> to 'edit' or 'open' that document, which should start the appropriate
> application.
>
> I can monitor when that process ends to know to read the document back into
> the BLOB.
>
> If my application is closed, I warn the user if any of the processes started
> has not been closed since being opened by my application.
>
> Does this sound feasible, or am I missing something obvious?
>
> Thanks,
> Johnnie
>
>

"Sean McCall" <NoSpam@nowhere.com> wrote in message
news:C784E26E-3931-4AB0-AEE2-566236341E42@news.elevatesoft.com...
> If you are not locked into using a BLOB, you could try an alternate
> approach. I just store information about documents in a database and store
> copies in a dedicated \documents folder under the database. I maintain a
> table of documents with a structure similar to this:
>
> SerialNumber: TLargeIntField (unique ID)
> ParentSerialNumber: TLargeIntField (record attached to)
> Description: TStringField
> Filename: TStringField
> Comments: TMemoField

I will be doing it all client/server, so I would have to do some tricky
server procedures to do that type of thing. I *am* going to make a backup
system for the documents table that allows creating a directory structure
with documents in individual files for archival purposes. Better safe than
sorry.

This project will get me to learn some things like drag and drop of files,
OLE automation, MSWord mail merge and other stuff. I'm jazzed to do some new
things.

Thanks for your example record structure (above). I'll be adding a few of
fields to mine: CreatedTimeStamp, UpdatedTimeStamp, UpdatedUserName, and a
LastViewed TimeStamp. At the request of one customer, a LOCK boolean, which
basically means that document cannot be changed or removed.

-Johnnie

For an example of how not to do it, you need look no further than Outlook
Express.  Open a Word attachment, edit it, close Word, lose your changes!

--Bill Sparrow--