Posted by
CARL Philippe (LBP) on
Jul 30, 2020; 7:48pm
URL: http://imagej.273.s1.nabble.com/Weird-behavior-with-GenericDialog-addImage-tp5023785p5023796.html
Hi Michael,
Your first suggestion was the good one!
Please find my code below:
try
{
url = getClass().getResource("/image/logo.jpg");
icon = Toolkit.getDefaultToolkit().getImage(url);
imp = new ImagePlus("Error message", icon);
gd .addImage(imp);
}
catch (Exception e)
{
IJ.showMessage("Loading the icon picture", "The icon picture \"/image/logo.jpg\" could not be found!");
}
The pictures were stored on the HD and I had 3 pictures (logo.jpg, logo2.jpg and logo3.jpg).
Also let me partially correct what I said this morning.
So going from a big picture to a smaller one, the issue was quite obvious since on the next compilation I (often = not always) got a big black frame (corresponding to the previous big picture size) within which the new (smaller) picture is pasted in and this magnetized at the top right border.
But going from a small picture, mostly the new picture gets correctly inserted, but sometimes (it seems to me when the size change is not too different) it gets also croped to the previous picture size.
I thank you very much for your help on this!
My best regards,
Philippe
PS: If you want to get my complete code I can as well send it to you if needed.
----- Mail original -----
De: "Michael Schmid" <
[hidden email]>
À: "imagej" <
[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 19:54:52
Objet: Re: Weird behavior with GenericDialog.addImage
Hi Philippe,
ok, I see, I have misunderstood it.
So where does your image come from?
Are you loading it as a Java as a resource? I.e. something like
URL url = this.getClass().getResource(path);
But then, how are you reading the image? Like this?
imp = new ImagePlus(url.toString); or
imp = opener.openURL(url.toString);
Just trying with JavaScript and scaled versions of blobs.gif like this,
I have no problem with images getting cached.
Michael
________________________________________________________________
On 30.07.20 16:05, CARL Philippe (LBP) wrote:
> Hi Michael,
> I already explained how I deal when working with .jar within my Jun 19, 2020 post of the following thread:
>
http://imagej.1557.x6.nabble.com/Compiling-directories-and-jar-files-rules-td5023539.html> I'm indeed modifying what was originally a .jar file, but I had previously moved the .jar out within the root folder (where the ImageJ.exe file can be found) and in my plugins folder I have only the .java and .class files of the the given plugin left.
> Also I only get the "memory issues" for the used picture size of the addImage method (when it is smaller), that is all.
> At last and not at least for all the other changes I make within the .java file, my code updates are correctly taken into account (which wouldn't be the case either if I would still have a .jar file containing the given .class file that could still "be seen" by ImageJ).
> Kindest regards,
> Philippe
>
> ----- Mail original -----
> De: "Michael Schmid" <
[hidden email]>
> À: "imagej" <
[hidden email]>
> Envoyé: Jeudi 30 Juillet 2020 15:32:48
> Objet: Re: Weird behavior with GenericDialog.addImage
>
> Hi Philippe,
>
> if you Compile&Run a class that is also in a .jar or .zip file in your
> plugins and that .jar or .zip was loaded when ImageJ was started, the
> following wil happen:
> It will compile the new version (and check for errors), but not replace
> the version from the .jar or .zip file, so it will execute the code from
> the .jar or .zip.
>
> If the previous version is only a .class file in the plugins, the
> replaced version will be used. I am not sure whether this is intentional
> or not (replacing one class in a .jar might lead to incompatibilities).
>
>
> Could this explain your problem?
>
>
> Michael
> ________________________________________________________________
> On 30.07.20 14:54, CARL Philippe (LBP) wrote:
>> Hi again,
>>
>>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>>
>> So what you you are doing is:
>> 1 - modify the .java code
>> 2 - save the .java code
>> 3 - launch plugins>compile_and_run...
>> 4 - close the obtained interface
>> 5 - launch Help>Refresh_Menus
>> 6 - launch the compiled plugin from plugins>your_plugin?
>> When I'm working on a plugin, I loop the described workflow from 1 to 3, that is all...
>> The only time you "normally" need to do Help>Refresh_Menus (or alternatively close ImageJ) is when you want tu run a given plugin from the Plugins menu and just saved it within the plugins folder or alternatively started with a brand new .java file that had never been compiled before.
>> Plugins>compile_and_run... is always overwriting the previously compiled .class file and launching the new compiled one (unless of course you don't have another .class file lost somewhere within your plugins folder that you don't remember about - which I have to admit happen to me a couple times already!!!).
>> My best regards,
>> Philippe
>>
>> ----- Mail original -----
>> De: "Gabriel Landini" <
[hidden email]>
>> À: "imagej" <
[hidden email]>
>> Envoyé: Jeudi 30 Juillet 2020 14:17:42
>> Objet: Re: Weird behavior with GenericDialog.addImage
>>
>> On Thursday, 30 July 2020 12:53:32 BST you wrote:
>>> I agree that the issue you are describing may indeed arise in the case you
>>> are compiling a code "outside" ImageJ (and then want to run it inside). But
>>> not when using the Plugins>Compile_and_run... tool directly within ImageJ
>>> (which is the way I always work).
>>
>> I thought that the menu is not automatically refreshed, because new plugins
>> run and compiled from within IJ do not magically appear under the plugins
>> menu.
>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>> Hopefully somebody can clarify whether the menu points to the newly compiled
>> class.
>>
>> Cheers
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html