Digital Workshop

Is it commonplace to have to rebuild resources or change the path for the resources folder after opening an Opus pub in the unzipped folder?

I am preparing to distribute the .imp file and its resources folder in a zipped package. I was surprised that the resources were missing when opening the .imp in Opus Editor, even though the resources folder was in the same relative path.

TIA

No it's not.

I frequently have to package the IMP and resources for clients and don't have this problem. As a rule of thumb, each project has it's own folder containing the IMP and a subfolder with the resources.

Mack

Thanks Mack.

Okay, I'll play around with that a bit more. Maybe keep it all on the C: drive (rather than the second drive/partition).
A more likely possibility is that I specified a folder/name for the 7-zipped folder that was different than my working folder.

I discovered another unrelated issue in the meantime. My .imp file almost doubled in size, when all I was doing was adding several Opus pages that contained ~only text... and then doing some save-as/versioning as I progressed. I must have done some other stupidish thing somewhere in there.

When I'm ready to store a project, I use Consolidate to place all my Resources into one sub-folder. OPUS will automatically re-direct the path names to your Consolidation folder, so you shouldn't have any missing resources. After Consolidating, use WinZip to compress everything into one file. When you Extract from Zip, you should be able to open your IMP file with everything pointing to your Resource folder.

Thx Fred.


I used to consolidate with almost every save.
However, when I am 'experimenting' or trying to fix something, I may have two versions of the Pub open in the Editor -- then various 'Save As' operations and the Consolidate process might move or merge resource files and one of the Pubs gets broken.

Suffice it to say I am confused in this area.

But in the case I am raising here, it was not an issue of missing resources at time of Saving. They are all there and working fine.
I had also done several Opus Backups (generating a Zip and including a consolidated Resources folder). However, not all files make it to that folder -- it seems Opus will not carry over .dll files and .db files.

So I'll figure a way through and see if I can settle on a workflow that works.

Cheers.

To be more specific, Opus does not add or consolidate resources used in OpusScript which would include your DLLs and SQL Lite DB files as well as any called graphics or audio. Oddly, it also does not consolidate icons used for publishing and some what annoyingly, it doesn't handle fonts too well either when sharing publications.

How are you managing the different versions? It works well, if they are all in the same folder calling on resources from the same sub-folder and of course it goes without saying - keep paths relative. For some advanced resource management IsPreview() is a life saver.

Mack

'Yes' that is what I do most of the time when I am building something complex and it takes time and iterations. Same folder, mostly. I just keep revving a suffix.
But then "I step over myself..." by doing some Save-as to a different folder (so I can keep the more experimental work apart). Then Opus does a nice job of using the PUBLICATION_DIRECTORY but sets the default name of 'Resource\' for the resources (or sometimes not-a-subfolder). After that I manage to scramble things up by quitting Opus, relaunching later and being prompted to open the Resource Manager.

None of this is ever FATAL, but I do manage to cause myself some busy work.

I am not too concerned now about the DLLs and .db files (though I wish DW would expand the scope of their utilities here). During all of the development work, it is easy enough to locate a copy of these and drag them in.

Which brings us to this point... of distributing a package. (As discussed in previous topics... leads to 3rd Party Installer/MSI -- when it comes to actually wanting an install performed). I would like to provision these kinds of SQLite + Opus pubs as EXEs to be run off of a thumb drive without an install -- while seemingly easy to do from a logistics standpoint, it is a little elusive from the standpoint of coding a proper path -- I am not convinced SYSTEM_PUBLICATION_DIR is the place I want it to be. 'Yes' I have started to use 'IsPreview'. It is in the upcoming Demo pub for just the reason you mentioned. Good stuff, that Opus there.

Have to wonder exactly what this tool would do? It sounds like you want something that would read the script, locate all coded resources and then what? I'm guessing package it up as a zip file ready to send so that it will extract to the same locations on others machines. This would be a nightmare, it would create all the paths that the developer had used for their resources on a third party's machine.

Or would it consolidate these scripted resources into the resources folder, in which case, it would have to rewrite the script to direct paths to the new location. But this means code would have to be rewritten by the third party if they want to run the publication with resources that were supposed to be in a specific location such as ProgramData or System32. Not to mention, that it would probably just be simpler to place the resources in the consolidate folder to start with.

Of course, this is assuming that any tool could work out which bits were resource paths in the script, which would be difficult enough for static paths, but what of dynamic ones built using known / runtime variable values or pulled from a database?

If you're looking to create portable applications, then MSI packagers are out full stop. They're designed for putting files in the right locations within an operating system. Portable applications are going to take one of several routes: either code resources to dynamic paths relative to the executable - so that everything runs from within one folder which can simply be zipped up and distributed.

Alternatively, look at application virtualization technology which works in different ways. Most, monitor a system for changes and then package programs into what is commonly known as 'portable apps'.

For source code distribution IsPreview() is great from the developer's perspective. It's also useful when switching between development / live systems NOT to use Opus' in-built system variables but to create your own global ones. This allows you to simply edit one line and switch all paths in a publication. I do this often with URL roots when developing for a database on localhost and my web server.

Mack

No.

I think somewhere along the line I mis-stated the problem. Or mis-stated my expectations.

Right now I have the SQLdemo.imp and a Resource123 folder.
Both of the two needed files, an sqlite3.DLL and the sampleDB.db, are in the resources folder (I may have manually placed them there at some point in time).

The issue I have is that the Opus Backup Publication feature -- does not include those two files in the zipped Backup. (they are lost from the Resource123 folder). But this is only a DEV-time issue and I am not concerned about that so much.

When I say I want DW utilities to be more comprehensive, I simply mean the Publishing process and the Distribution Wizard.

Of course, the burden is on me to just take-up and learn to use MSI or other Installers. (as for the portable and thumb-drive issue, that is a simple matter of placing the files on an SD Card or Flash Drive. What I would have to work out is scripting the paths to the .DLL and the .db file. --- I will work on that some future date)

Am very buzzy tired now. So will have to postpone any heavy thinking on this. Thanks.

(the consolidate folder --- that may be not-so-easy when I want to offer multiple .ILM modules and a single EXE)

- - - - - - - - - - -
I almost forgot... on the OP, I discovered that my problem (the problem I caused) was that I was naming the 7-zip compressed folder different that the existing folder. It is much simpler to not change anything -- and it worked fine! So case closed on the OP. And I'll get the package up on your site very shortly. Thanks again.