Jump to content

Kevin Lane

Members
  • Posts

    8
  • Joined

  • Last visited

Kevin Lane's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. Is there a way to completely disable the upload feature in the SC webviewer? I can obviously hide the upload button, but the user can still drag and drop. I need to remove the drag and drop ability, and simply show the image at the URL.
  2. Thanks so much, Smef. I think I got things figured out. One of our last must-haves to a replacement for our current photo library solution is a way to burn a disc with all the patient images. Does supercontainer have a slick way of exporting or downloading (I guess recursively?) all files in a specific folder? My current path setup is: Supercontainer/Files/Photo Libraries/patientName/eventName/serialNumber/image.jpg I would need to get everything inside eventName, downloaded to the desktop to burn. Perhaps a shell script would be best, but maybe supercontainer can do this?
  3. Thanks for the quick reply. I see, I can choose the location with SCDownload; one quick question, what is the filepath (of the file I am downloading) relative to? Can I simply use cResourceIdentifier, or cFilesURL, or some other path relative to /SuperContainer/Files ? I plan to always download TO the desktop, so no problem there. The reason I want to be able to calculate the full path, including the file name, is to be able to do other tasks not using SuperContainer, and to not have to know the actual file name. We may want to run a shell script to rotate the image 90 degrees, but I need to be able to calculate in the image name to do this, not just the directory in which it lives. I have tried the SCGetInfo with no luck, but I believe I am not putting in an appropriate path. My question there is the same; which path to feed the function? The full, http:// path, or some other relative to the supercontainer directory?
  4. I am using SuperContainer to upload medical images to a server, which is working fine. But, occasionally we have need to rotate or otherwise edit the images. I understand the availability to download the image, edit, and then re-upload, but I have run into a few issues. 1. The location where these downloaded images are stored is far from convenient; is there a way to change this default download location to a folder on the desktop? 2. I would love to be able to calculate the FULL filepath to the image, not just the folder containing the image. Is there a way to set a field to only the name of the image? So for example, I have uploaded an image, store at /SuperContainer/Files/Photos/PatientName/Date/image1234.jpg Is there a way to set a field to just the "image1234.jpg" during the upload process? If there is a better solution for basic image editing and manipulation, I would love some ideas. Thanks Kevin
  5. Thanks for the reply. I have done some testing, and things are working brilliantly, except for one issue, which I think it most appropriate I post a separate topic. Thanks!
  6. I have read through the documentation, and looked over the forums, and cannot find (or missed) the answer to my simple, and probably obvious, question; does the supercontainer java servlet need to be running on the server, AND all the client machines, or just the server? We are going to move forward with testing on our server soon, and would be nice to know before then. Thanks
  7. Thanks for the feedback, everybody. I am not quite sure how better to describe my dilemma to avoid confusion, but I think you all get the gist. I have a rudimentary (but growing) grasp of relationships. I have been able to build a database that can gather patient info, create reports, create monthly reports based on those reports, etc. Right now, I am using one large table, with 500+ fields to cover every type of report we do. Here's what I understand as of now. Pros - of using one large table 1- easy to show all related reports in one portal on the patient page 2- keeps the relationship outline pretty simple 3- My report layout seems simple, with only one layout needed to display any type of report. The different info for each report is stored in a tabbed section in the middle of the page, and depending on the report type, I automatically go to that particular tab Cons - of using one large table 1- Possible waste of space (if, indeed, hundreds of empty fields in every record created DO take space, which it seems you are saying it won't) 2- Scrolling through 500+ fields to find the field I am looking for, no matter how well named and organized, is a little tedious. It seems my major beef with using one large table is the ability to display all related reports in one portal. More and more people seem to suggest it's possible to show records from multiple tables in one portal, through relationship magic (probably not very magical once you know how to do it), although I have not been able to find a way to do this. Can someone suggest a resource to help me figure this out?
  8. Amateur FileMaker developer here, working on a solution for a medical reporting database. Simply, I have patients, and those patients have reports that belong to them. Now, there are numerous report types, 15-20 of them, each with different criteria (fields). My questions are these: Do empty fields take up space in the file? Meaning, if I use ONE table to create ALL the report types, creating 400-500 fields in this table and using a tabbed interface to display the fields for each report type, will it drastically increase my file size after several thousand reports when most of those fields will be empty for each record? The only reason I have it set up this way currently is because I have yet to find a way to display records related to the patient from many different tables (many different report types). If I set it up using different tables for each report type, can I show all the reports related to one patient in one portal from all these different tables? Any feedback / advice is greatly appreciated, thank you.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.