Make image display in a scroll window...

can anybody help me out with making an image display in a scroll window and flip to the next picture when the scroll button is clicked? I am trying to create a simple image manager Applet.
i have tried to use a regular scroll bar but I can only get it to work with a textbox not an image, does anybody know how I can do this.
thanks

This is what I have but it is quite plain... I want it to do more like select different categories. and maybe do a slide show or something... any suggestions??
import java.awt.*;
import java.awt.event.*;
import java.applet.*;
public class imgViewer extends Applet implements ActionListener {
   private Button show, next, prev;
   private Image pics[] = new Image[9];
   private String [] gifName = {"img4", "img2", "img3"};
   private int currentImage=1;
   Panel p1;
public void init(){
      for (int i = 0; i < gifName.length; i++) pics = null;
      Panel p1 = new Panel();
      show = new Button("Show");
      p1.add(show);
      show.addActionListener(this);
      next = new Button("Next");
      p1.add(next);
      next.addActionListener(this);
      prev = new Button("Previous");
      p1.add(prev);
      prev.addActionListener(this);
      add(p1);
   public void update(Graphics g) {
      paint(g);
   public void paint(Graphics g){
      Image image = getImage(getCodeBase(),gifName[currentImage]+".jpg");
      g.drawImage(image, 40, 40,200,200 ,this);
   public void actionPerformed(ActionEvent event){
      if (event.getSource()== next) {
         currentImage++;
         if (currentImage>=gifName.length) currentImage=0;
      } else if (event.getSource()== prev) {
         currentImage--;
         if (currentImage<0) currentImage=gifName.length-1;
      repaint();
}

Similar Messages

  • Image display control scrolling does not work properly when zoomed in

    I am using a ROI on an image in the image display control. When zooming into the image to fine-adjust the positioning of the ROI, the image scrolling does not work properly. As far as I understand, the image should scroll automatically when the ROI is leaving the visible area. However, the scrolling behaviour seems to depend on the origin of the Labview panel, not the origin of the image display control, which might require to move the ROI way out of the visible area before the scrolling takes place. In other words: the coordinate system of the image display control is shifted with respect to the true visible image area, depending on where you place it on the front panel. As a consequence, when clicking on a ROI which is in the visible area, but is outside of what Labview thinks is the visible area, it might immediately jump to the left border of the image, making the positioning of the ROI really difficult.
    Has anyone noticed this behaviour, and what would be a reliable solution to avoid this? 
    Dirk

    Hello,
    no, I am not talking about the tools palette. Just place an image control with some image in it on a new VI front panel. Then, use the rectangle from the tools and select a ROI in the image. If you zoom in (using the magnification glass), and then grab the ROI and move it around, the image scroll with the ROI. So far, so good. If you now place the image control elsewhere on the panel, or add new control above it, resize the panel, etc. , this scrolling when moving the ROI will not work correctly if the origin (0,0) of the panel is far away from the image control.
    I have attached a VI for simplicity (although there is hardly any code in it).
    If you make a ROI and try to move it down, you will notice that scrolling starts if you move the mouse out to about 10cms below the image (depens on your screen, of course). After that, if you click on the ROI, the scroll bars and ROI might jump up to the upper end of the image. Imagine how annoying this is if you try to finely adjust the ROI position. 
    I think it is a bug in the implementation of the image display control.
    Thanks,
    Dirk
    Attachments:
    scrolling.vi ‏818 KB

  • The window displaying bookmarks is too large (suddenly happened with the new version). I can't figure out how to make the display smaller. Zooming out does not work on the bookmark menu display.

    I have version 4, just downloaded, and a Mac w. OS 10.6. 7.
    The bookmarks display (when I pull down "bookmarks") is much too wide. I can't figure out how to reduce the display size. The window is not persistent so I can't even get you a screen shot.
    Thanks, Sara

    It seems there was a change in Firefox 4 where the width of the drop-down is now determined by the length the longest bookmark name in the folder being displayed. Previous versions of Firefox would shorten a long name like that and add an ellipsis to signify the name was truncated.
    Sorry, I don't know how to change that other than to advise you to edit the name of that long bookmark name and make it less verbose. Just scroll down the list of bookmarks in that wide folder until you see the culprit, then right-click that bookmark and open Properties & edit the Name line at the top of that dialog.

  • How can I use my Mac G3 (OS 9.2.2) to make Windows disk images and compress them into Windows stuffed archives?

    I have a collection of old Windows diskettes, 800 K and 1.4 MB.  I want to make disk images (or whatever is the Windows equivalent) and compress them into Windows stuffed archives.  I want Windows users to be able to download them, expand the stuffed archives, extract the disk images, and use the softsare on old Windows computers.  I need to do the work on a Power Macintosh beige G3 Tower using OS 9.2.2.  What software can I get to do it?

    To Jan, Greetings
    Thank you for your message and for your suggestions.
    Is WinZip a Mac application that makes compressed files that can be opened on a Windows computer?  If so, then do you have any notion where I could find a version old enough to run on OS 9.2.2?
    I noticed that DropStuff 6.0, which I use on my G3 Tower, has an option to make compressed files that are self-extracting on Windows.  Do you know if that works?  I suppose that I could make such a file and then find somebody with a Windows computer to test if for me.
    Yes, I could (shudder) get an old Windows computer somewhere, learn to use it, and do the project that way.  Do you know if the old versions of Windows include disk image programs and file compression  programs?  Or, would I need to buy some old software?
    Thank you for the information about the size of the diskettes.  As you've probably noticed, I don't know very much about Windows things.
    Sincerely,
    Frontiersman

  • Image display scroll bar

    Hi All,
    I am using two "Image displays" in my IMAQ vision system. One is for the original image and the other is for the image after it has been manipulated. I would like to connect the scroll bars from each display to move as one.  Anyone have any idea how to do this?
    Don

    Here is a present from Santa.  It is in LV 8.0.  Enjoy
    Matthew Fitzsimons
    Certified LabVIEW Architect
    LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
    Attachments:
    IMAQtrackImages.vi ‏62 KB

  • How do I make image icons in finder window previews of the image?

    The image icons in my finder window are just generic jpeg icons (they are set to open automatically in Preview). How do I make them previews of the images themselves? When I "get info" on the icon, there is a very nice preview of the image - I would like to see the same quality preview in the icons themselves.
    Thank you very much for your help.
    Sam
    Powerbook   Mac OS X (10.4.6)  

    Hi Sam,
    From your Finder "View" menu (without a Finder window open) >> "Show view options" >> do you have "show icon preview" check marked? And with the Finder window open "show icons" and "show preview icons" checkmarked?
    EDIT: I may have misunderstood your question. If you're talking about the small file icons, not in the preview frame if you have PhotoShop it should do it with a save as PS file. Otherwise you may be able to paste the image but I'm not sure.
    -mj
    [email protected]
    Message was edited by: macjack

  • When I change the time zone of the clock, the "Date created" time information for my documents and image files in the Finder window (and in Get Info) is changed. Can I make the time info in "Date created" remain fixed regardless of the clock's timezone?

    When I change the time zone of the clock, the "Date created" time information for my documents and image files in the Finder window (and in Get Info) is changed. Can I make the time info in "Date created" remain fixed regardless of the clock's timezone?

    When I change the time zone of the clock, the "Date created" time information for my documents and image files in the Finder window (and in Get Info) is changed. Can I make the time info in "Date created" remain fixed regardless of the clock's timezone?

  • Can I make an image display instead of flash slideshow on explorer with high security?

    I am a total flash beginner.  I created a simple flash slideshow that I want to appear on my website.  It works fine in firefox., but when viewed in explorer with high security, nothing displays unless the viewer specifically allows it. The slideshow is very prominent, and the site looks very bad when only an x shows up.   Is it possible to have a static image display in place of the slideshow, and then have the slideshow start if the viewer allows it? Is there any other way to get around this? 
    Thank you for any assistance.
    EJ

    Have you tested it with IE online or only locally?  Locally IE will usually prohibit displaying Flash content.

  • Why does moving the mouse over an IMAQ image display slow the GUI down so much?

    I have a large application with several vi's running simultaneously under labview 8.6.1.  When I mouse over an image display control in one of the vi's, everything slows down a shocking amount in all the other vi's.  The windows task manager does not show a large increase in CPU use.  My pc is has a quad cpu with 4GB of RAM, and the CPU and memory loads do not appear to be terribly taxing to the system.  However, many of my vi's apparently come almost to a standstill if I just move the mouse in a circle around my image control.
    This looks like it is largely a GUI display issue.  If I make a new vi and put a while loop in it that only displays the iteration loop number to an indicator, I can see the iterating occurring, then stopping totally when I mouse inside the image display control.  When I stop moving the mouse inside the control, or when I move it outside the control, the interation loop number jumps up, as if it had been incrementing behind the scenes the whole time.  So only display of the interating was halted.
    This problem occurs even if the vi with the image control is not executing.  If the vi with the image control is open but not running, and I mouse over the image on it, the other guis all come to a screeching halt.
    Does mousing in the image display control really utterly crush all other guis in all other labview windows?  Is this an issue inherent to the image display control?  If so, is there anything I can do about this? 
    Also, this issue is not entirely limited to display.  I started looking at it in greater detail because this issue also exposed what I think is a race condition in my code.  I have a vi that acquires an image from a ccd and puts it into an IMAQ image.ctl.  This image then gets passed up to a vi up the call chain, and is put on a queue and sent over to be de-queued by a vi that has the image display control.  Here's the kicker:  when I mouse over the image display control, the image successfully gets acquired inside the subvi, and if I probe the wire leading to the output IMAQ image display.ctl, I see the image.  If I simultaneously probe the wire coming out of the subvi one level up the call chain, the image gets lost about half the time.  This only happens if I am mousing in the image display control IN A TOTALLY DIFFERENT AND SEPARATE VI.  If I bump up the priority of the ccd image acquisition vi to 'highest priority', the problem only happens about 1% of the time, and I really have to mouse around to make it happen.  Still, it's disturbing that mousing in the GUI in one window results in a failure of a separate subvi to simply pass an image up the call chain.  I understand that IMAQ images are referenced rather than passed by value, but I don't see why there should be a failure to pass the image up the call chain.  I've looked for a race condition, but can't find one.
    Eric

    I have finally been able to replicate the behavior that you are seeing on another computer once the image was large enough.  Here are a few notes about this behavior:
    First. The UI only slows down when the images are large, 16 bit images.  The reason why this is unique to 16 bit images is that they can only be displayed on the front panel as 8 bit images.  The workaround that Weiyuan suggested to change the 16 bit display mapping hints towards the root of the problem...that any time a mouse runs over the indicator, Windows asks the entire image to re-draw (having a separate indicator overlapping the image will create the same behavior).  With a 16 bit image, not only does the image have to re-draw on the screen but the 16 bit pixels need to be mapped to 8 bits.  When setting the 16 bit display mapping to Full Dynamic, this requires mor computation/pixel than 90% dynamic or one of the other mapping schemes.
    This is expected behavior if your program is running and you're trying to display a large 16 bit image.  To fix this behavior there are a couple options:
    Change the 16 bit display mapping to something other than full dynamic.  You can choose which 8 bits to display or if you want to map the bits. 
    Resize the image just for viewing purposes on your front panel (since you aren't going to view every single pixel of you image on the screen). You can use the IMAQ Resample.vi to do this.  This will allow you to take your 1500x1500 pixel image and only display a 500x500 pixel version.
    If you are interested in viewing small details of the large image, consider just displaying a smaller region of interest at a time.
    Let me know if any of these solutions work for you.  Good luck on your application.
    Zach C.
    Field Engineer
    Greater Los Angeles

  • Image Display got rotten (really: the Indicator, not the Image!)

    I'd like to hear comments on the following VI, containing just a single Image Display Indicator, which, for some reason got corrupted during porting across LV versions and resizing. By divide and conquer I found that it was the origin of pretty odd problems that I was observing in a complex VI: absence of front panel updates, pull down menues not displayed, actions needing a double press of buttons, and so on.
    The VI is saved from LV2012 windows, also attached as saved for 8.5. Just opening it, on 2 installation of Labview, I turn labview into something responding oddily. (try to pull down a menu, e.g.). Linux LV seems not to suffer from it, maybe because it places a nonfunctional FP placeholder for this control, without trying to cope with its nonfunctionality.
    The question is perhaps, why LV doesn't detect the problem and behaves so weirdly with it -- bug?
    Enrico
    Attachments:
    BadImage.vi ‏34 KB
    BadImage85.vi ‏36 KB

    Yes, I was able to see this trouble as well. Checked in different versions (2010 and 2012 x86/x64). But was unable to re-create this VI from scratch. It seems to be that Vision Control was broken in customization attempt where cluster with buttons was rearranged from vertical to horizontal position (may be in combination with saving for previous LabVIEW version).
    Time to time I do the same (for example save VI with vision controls from v. 8.6 to 7.1) and I've got lot of situations when "downgraded" VI cannot be opened or caused just crash, or broken. Something is wrong.
    Quick and dirty analysis of the given "BadImage.vi" shows that the problem with refreshing is present. LabVIEW tries to refresh this control continuously.
    In Process Explorer we can see one thread with 100% CPU load (overall 20-25 percent, because I have 4 CPUs):
    In Call Stack we may see DrawImageControl function which is called from niviswnd.dll.
    Well, load this stuff into debugger, set breakpoint and see - this function called continuously:
    called somewhere from SetPIClusterPartSize from LabVIEW.
    I don't want to go deeper into call chain analysis (anyway makes no sense without source), but short walking in debugger shows that messages continuously fired:
    Check it with Spy:
    There are thousands WM_PAINT messages which continuously sent to the Window with this weird control. Looks like attempts for update, but due some internals errors this called again and again.
    The messages queue is full with WM_PAINT - therefore LabVIEW is "unresponsive" - context menus cannot be shown, dialogs cannot be closed, slow reaction, etc.
    Sorry for slightly off-topic above, but may be this will be helpful for NI's engineers for further investigation.
    Andrey.

  • ACR 6.3RC still makes Bridge display some TIFFs & JPGs overexposed

    I had the same problem with TIFFs & JPGs after upgrading from ACR 6.1 to 6.2. My system is Win 7x64 and, of course, PsCS5 and Bridge 4.0.39. This time the upgrade was from ACR 6.1 to 6.3RC. Not all images are affected. The problem seems to be entirely random. The amount of overexposure seems to be in the order of 1 to 2 stops. The problem is limited in this way for me:
    1. All the affected images display correctly exposed when opened in Ps and ACR 6.3RC (and ACR 6.2) hosted by Bridge.
    2. Only TIFFs & JPGs (both B&W and Colour) "derived" ultimately from original TIFF scans (both B&W and Colour) made on a Nikon SuperCoolscan 5000 ED are affected. The original TIFF scans (99.99% are 16-bit) are all unaffected.
    3. The problem does not occur with any TIFF or JPG file derived from native CRW or NEF raw files or from native JPG files produced in-camera (Canon EOS 300D and Nikon D700), all of which are themselves unaffected.
    4. It does not matter were you might be in an image editing process. Some intermediate edits to TIFFs (I never make intermediate JPG edits) are affected, others are not. Editing might start with the TIFF and continue with edits to the TIFF, and only some of the subsequent TIFFs (or final JPGs derived from them) are affected. For example, there might be 6 distinct edits to a TIFF and only edits 3 through 6 are affected. Editing might procede immediately from the original TIFF scan to PSD, finalise with PSD, and then, AND sometimes only, any TIFF or JPG made from the final, flattened PSD produces a file which Bridge will display overexposed. Only some files in a batch of scans, all made at the same time and under exactly the same conditions (almost always with no adjustments made with the Nikon scanning software), are ever affected - never all of them.
    5. Some of the edits to the original TIFF scans (where the edits were kept as TIFFs) were made with Picture Window Pro, some with Lightroom 1.3 (I think), some with ACR 4.x, ACR 5.x, but most were made with PS CS3, CS4 and CS5: it does not matter, there are some affected files from each. The problem certainly does occur with files which have never been opened, let alone edited, in any version of ACR.
    6. I have several instances where simply making a copy of a TIFF scan in another folder (whether the copy was made by Bridge or with Windows Explorer has no influence) results in the copy only and not the original being displayed overexposed.
    7. If a file is affected, all TIFFs AND all JPGs derived from it will be overexposed, never just one or the other.
    The overexposure problem detailed above does not occur with ACR 6.1. All the files affected by ACR 6.2 and 6.3RC are displayed with correct exposure by Bridge when ACR 6.1 is installed.
    I'm at a complete loss to understand what is going on. Any suggestions would be most welcome.
    Has anyone else who was experiencing the Bridge/overexposure problem with either ACR 6.2 or 6.3RC found a solution?

    This will be posted in both the ACR and Bridge User Forums
    I've done some experimentation and found a workaround for, not the solution to, my problem with ACR 6.2 and 6.3RC causing Bridge to display random TIFFs and JPGs overexposed.
    This is a temporary, and, if you have lots of affected files, a very laborious, individual file workaround. Unless Adobe investigates, finds and corrects the cause of the problem, it seems likely to re-occur. Only fixing the cause of the problem (which must lie in the new (different from ACR 6.1) code of ACR 6.2 and 6.3RC) could be be truly regarded as a solution.
    Here is how I enabled Bridge to display my affected TIFFs and TPGs correctly, that is, with no amount of overexposure. These steps apply equally to B&W and Colour images.
    For a 16-bit TIFF, duplicate it in Bridge (Edit/Duplicate) and then open the duplicate in ACR 6.2 or 6.3RC (ACR) hosted by Bridge. Make sure that all the sliders are zeroed in the Main panel and that the Amount slider in the Sharpening section of the Details panel is also set to zero (to avoid unwanted additional sharpening). Then open the image in Photoshop (Ps) and immediately save the image (Save As) over itself (yes, you're replacing the file) back in the folder from which you opened it into ACR, making sure to choose no compression. The resaved duplicate will now be displayed with its proper exposure in Bridge, and any further TIFFs or JPGs (whether 16-bit or 8-bit) derived from this file will also be displayed correctly. Following this procedure, my invariable experience is that I end up with a TIFF either the same size as or smaller than the affected TIFF.
    Why no compression? Strangely, if you choose LZW compression (really the only logical alternative to "None") you end up with a larger file than you get with no compression. I have no idea why. Why not simply fix the affected file instead of a duplicate? No reason really, other than safety. If things go belly-up you still have your original, albeit, affected file. I also intend to keep my affected files for awhile just in case of some possible desire or need to re-examine them in the future.
    For an 8-bit TIFF, although I don't have any which are affected, the procedure would be the same as for a 16-bit TIFF. You will need to conduct your own tests regarding compression/no compression and the resulting file size.
    For a JPG, the procedure is pretty much the same (duplicating, opening in ACR, zeroing all sliders, opening in Ps and then saving over itself) but when saving try choosing Maximum Quality (12) which mostly, for me at least, produces a replacement JPG the same size as the original affected file. Of course, you can choose a greater level of compression if you wish, and my tests show that this will not adversely affect the outcome. You can use the replacement JPG to produce further, derivative 8-bit TIFFs or JPGs and all will display properly exposed in Bridge.

  • Photos in album are only a hash-marked outline the image only shows when scrolling how can I see the image and open the photo?

    Photos in iPhoto album are only a hash-marked outline the image only shows when scrolling how can I see the image and open the photo?

    Make a temporary, backup copy (if you don't already have a backup copy) of the library and apply the two fixes below in order as needed:
    Fix #1
    Launch iPhoto with the Command+Option keys held down and rebuild the library.
    Select the options identified in the screenshot. 
    Fix #2
    Using iPhoto Library Manager  to Rebuild Your iPhoto Library
    Download iPhoto Library Manager and launch.
    Click on the Add Library button, navigate to your Home/Pictures folder and select your iPhoto Library folder.
    Now that the library is listed in the left hand pane of iPLM, click on your library and go to the File ➙ Rebuild Library menu option
    In the next  window name the new library and select the location you want it to be placed.
    Click on the Create button.
    Note: This creates a new library based on the LIbraryData.xml file in the library and will recover Events, Albums, keywords, titles and comments but not books, calendars or slideshows. The original library will be left untouched for further attempts at fixing the problem or in case the rebuilt library is not satisfactory.
    OT

  • Dynamic image displays depending on yes / no value

    Dynamic image displays depending on yes / no value    
    I´d like to have a image showing, depending on a specific value (y/n)
    ..sorry need some help.
    I can´t get it workin.....
    <img <?php $status="n";
    if ($status == "y") {
      echo 'src="stecker_on.png" alt="yes"';
    } else {
      echo 'src="stecker_off.png" alt="no"';
    } ?> height="71" width="101" />
    The image ist not showing... ideas ?
    All I get ist some text showing:
      height="71" width="101" />
    MANY THANKS !!!!

    Presumably you mean this -
    http://mediaconsults.de/1test/steckertest.php
    And it's not clear what that is going to show me.  Looking at the code on the page -
    <html>
    <head>
    <title>Unbenanntes Dokument</title>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <script language="JavaScript" type="text/JavaScript">
    <!--
    function MM_reloadPage(init) {  //reloads the window if Nav4 resized
      if (init==true) with (navigator) {if ((appName=="Netscape")&&(parseInt(appVersion)==4)) {
        document.MM_pgW=innerWidth; document.MM_pgH=innerHeight; onresize=MM_reloadPage; }}
      else if (innerWidth!=document.MM_pgW || innerHeight!=document.MM_pgH) location.reload();
    MM_reloadPage(true);
    //-->
    </script>
    </head>
    <body background="test%20png.png">
    <div id="Layer1" style="position:absolute; left:1290px; top:246px; width:95px; height:112px; z-index:1"><img src="stecker_off.png" alt="no"height="101" width="71" /></div>
    </body>
    </html>
    I would advise you the following:
    1.  Put a valid and complete doctype on that page!
    2.  Get rid of the resize if NN4 javascript - it hasn't been needed for nearly a decade.
    3.  Fix your image code (note the missing space after "no"!
    4.  1290px is way too wide unless you want lots of people scrolling right to see things.

  • Part of image display gone..

    Like this..
    when i moving that window, image come back.
    But when i trying to work, image display gone...
    How to fix it?

    If you blur everything out it makes it impossible to see whether something you've done might be causing the issue.
    If it truly is a system glitch, and not an accidental layer you've overlaid or something, you may need an updated display driver.  Visit the web site of the maker of your video card and download/install the latest display driver release for your OS and hardware.
    Failing that, try going into Edit - Preferences - Performance, [Advanced Settings...] and changing the Drawing Mode.  Make sure to close and restart Photoshop after making a change there and before testing.
    Good luck.
    -Noel

  • Using IMAQ Image Display control vs IMAQ WindDraw for large image files

    Hello All;
    I am designing an application that is currently using IMAQ Image Display control to view large images (5K x 3K and larger).  My problem is that these images take 10-20 seconds to load and display, whereas if I use IMAQ WindDraw to display my image in a separate window, it only takes a couple of seconds.  My application is designed such that I am making use of the Subpanels in LabVIEW 8.0, and to make it pleasant for the user, the interface is such that my line profile, histograph and image viewer displays are contained within the same GUI (panel).
    I read the National Instruments application note regarding displaying of large images, and it did not seem to make a difference.  For example, I switched the 'modern' IMAQ Image Display control with the classic Image Display control, since the 'classic' does not contain any of the 3D rendering tools which might slow the process down.
    Why is there such a huge difference in loading times if I am trying to do exactly the same thing with both methods?  How can I bring the IMAQ Image Display control up to the same speed as the IMAQ WindDraw tool?
    I am currently using LabVIEW 8.0 with the latest IMAQ/NI Vision package from NI (IMAQ v7.1?).  Thanks.
    DJH

    Use a property node and select 16 bit image mapping. You can create a control for this or whatever you need. If you select the individual elements, you can get enumerated controls.
    Bruce
    Bruce Ammons
    Ammons Engineering

Maybe you are looking for

  • Composite video out on tx2520ej

    I've got an HP tx2520ej laptop with Radeon HD3200 chipset and s-video out. I want to connect it to the TV by using a composite video signal. Can i get composite signal from the s-video out port like shown on this pic, or the mobility radeon chipsets

  • OBIEE 11g Map question

    Hi all, We are using OBIEE 11g Mapviewer to display some results. We have point as well as polygon location geometries which combined with other dimensions display scores on the map. It seems there is a restriction on the display graphics that can be

  • Slice and dice in webi

    Hi, Can you do slice and dice in webi? If yes, please tell me steps to be required. If no, please tell me for which tool these are possible in BO environment Thanks and Regards, Manjunath

  • Why can't I use microsoft office anymore since I upgraded to Lion?

    Since I upgraded to Lion I can't use any of the microsoft office applications. I need to access Excel for work.  Any suggestions as to why or how to address this issue? Thanks

  • Phone shuts down when i want to snap

    My bold 4 goes off when I ever I want to snap picture and will not come up with power button unless when charger is plugged. Please what should I do.