The following is my requirement:
I have an image file called "Test.jpg" in a path say c:\. I'll change that image every one minute, but with same path and same file name. I want that image to be loaded in crystal report (Business objects) and that image should refresh according to the image change.
How would I do this?
Related
I have a jsp page where in I upload an image(MultipartFile) and store the image name in database and the image file in a central repo.
Now when I want to edit the image (when the page loads) the image gets displayed as the src is the actual path from repo. However now if I just save it the fileName is empty.
Is there any way that I can get the fileName
The new TinyMCE 4.3 Image Tools (eg when cropping) saves images as blob data instead of image files in a directory. the edited mage url is like
blob:http://www.example.com/f2953aa1-e64f-49e1-a6e3-a283986663bf
I want to upload the image file to a specific folder and then use it as regular image referance / path.
Note
The question I am going to put is similar to Image edit issue. but the answer to this question is not working. I also tried http://archive.tinymce.com/forum/viewtopic.php?id=35740 solution but not working because it produces always same name image name.
The basic process is that TinyMCE will create a separate HTTP POST for each image that you modify with the image editor. It will send that image to a URL of your choosing (via HTTP POST) based on the setting of the images_upload_url option in your init.
The image handler at the URL referenced in the images_upload_url (which you have to create) has to do whatever needs to be done to "store" the image in your application. That could mean something like:
Store the item in a folder on your web server
Store the item in a database
Store the item in an asset management system
...regardless of where you choose to store the image your image handler needs to return a single line of JSON telling TinyMCE the new location of the image. As referenced in the TinyMCE documentation this might look like:
{ location : '/uploaded/image/path/image.png' }
TinyMCE will then update the image's src attribute to the value you return. If you use the images_upload_base_path setting in the init that will be prepended to the returned location. The TinyMCE page has more details on all of this:
https://www.tinymce.com/docs/advanced/handle-async-image-uploads/
The net here is that TinyMCE knows when an embedded image exists in your content but it can't possibly know what to do with that image in the context of your application so that job (the "image handler") is something you must create.
I want to change image in my crystal report dynamically in my Asp.net Project. So I used Picture field and set the path in "Graphic Location".
It's working fine when I give the path of external image like this "F:\abc.jpg".
But I want to give the path of image which is inside my project let's say I have a folder in my project "Images" which contains all images. So I want to set path like this "Images/abc.jpg"
How can I do this ?
I'm attempting to modify an inherited project that has a convoluted process of displaying uploaded images using an ImageMap control.
The current process inserts a new database record with image file name as well as model number and part number. The image files are saved to a virtual directory visible to IIS. Each part number has a corresponding .htm file containing an image map referencing the uploaded image. The image map has to be sized for each part and saved in the file system.
How can I streamline this process using either client side or server side controls? I'd like to bypass use of image maps as they require manual sizing. Can a control be used that auto sizes the image? Should the images be stored inside the database or kept in the file system?
Thanks for your advice;)
Storing the images in the database is IMHO a much more scalable solution.
Take a look at the Image Resizer project and its associated plugins for a way to resize the images, regardless of where you store them:
http://imageresizing.net/
http://weblogs.asp.net/bleroy/archive/2011/10/22/state-of-net-image-resizing-how-does-imageresizer-do.aspx
http://nathanaeljones.com/163/20-image-resizing-pitfalls/
You could use regular ASP.NET controls to display the images, for example, a ListView.
I have an asp.net 2010 project. I write a jpg to the filesystem. Then I display it in an Image control. Then I use this code on button click to allow the user to rotate it 90 degrees.
string path = Server.MapPath(Image1.ImageUrl) ;
// creating image from the image url
System.Drawing.Image i = System.Drawing.Image.FromFile(path);
// rotate Image 90' Degree
i.RotateFlip(RotateFlipType.Rotate90FlipXY);
// save it to its actual path
i.Save(path);
// release Image File
i.Dispose();
It does rotate (I can actually watch that happen in Windows Explorer). But when I run the app again and it grabs the file from its path, it still displays it in its original form.
Try adding a dummy querystring to the end of the image like "image1.jpv?v=1". This works to prevent caching for things like Javascript files and it may do the same for you.
This is the classic issue with browser-cached resource files. Alison's answer is one option. Another option is to change the name of the physical file. If you "version" the files, then after each change, the file name will be different. This does mean that you'll have to dynamically reference the image path so that you display the correct version, and you'll need some way to determine the file name for the current version. It does prevent the browser from displaying the previously cached file immediately after a change, though, because it's technically a new file to the browser at that point.
If you are using some sort of data source (XML files or database) to store metadata for the images, then you can add a "Version" column and store a simple integer. With each change, increment the integer value and use the new value in the file name. You can even extend this by saving the previous versions and allowing your users to "undo" actions by copying an older version of the file into a new version. This might require a more robust metadata storage implementation, though.