Jump to content

alexo

Members
 View Profile  See their activity

  • Posts

    72

  • Joined

  • Last visited

 Content Type 

Posts posted by alexo

    Error Copying To Clipboard in v3.5.7

    in Troubleshooting & Bug Reports

    Posted

    I just installed 3.5.7, and now I'm having trouble with the copy command (both CTRL+C and Edit->Copy). The error I'm getting is "There was an error copying the image to the clipboard". This was working in the previous version I had installed (3.5.6). I think it might be related to the number of pixels selected. 2520x2848 produces this error, whereas 2377x2395 doesn't produce the error.

    I'm running Win XP Pro 32-bit with 4gigs of ram on a quadcore processor (Q6600), so I should hope it's not running out of memory.

    I started having this problem in 3.5.10. It would not copy images larger than about 400K pixels, which is really quite small

    Windows paint has no problems with images even larger than that.

    Any ideas? I can't work... :(

    That other app v2.2

    in Plugins - Publishing ONLY!

    Posted

    Hello Simon,

    Thank you for your reply.

    There isn't. What do you want to remove? If it's objectively unhelpful I may be able to blacklist it in an update.

    I find the forced autodetection feature is subjectively unhelpful.

    In the screenshot below, it shows me 42 icons, out of which I currently use exactly one program and may conceivably use another.

    In other words, 95% of the icons are not needed. And that is without mentioning duplications.

    What I would like is the ability to turn autodetection off and instead use a set of predefined applications.

    Is it feasible?

    Best,

    Alex.

    thatotherapp.th.png

    • Upvote 1

    .NET version

    in Troubleshooting & Bug Reports

    Posted · Edited by alexo

    Thanks pyrochild.

    Have you tried repairing it?

    I uninstalled it completely and now it does not want to reinstall.

    I highly recommend you get .NET 3.5 working

    You and me both. Unfortunately, my computer does not concur.

    I opened a thread on the MSDN forums, hopefully I'll get some useful answers.

    How to do "fakes" in PDN?

    in Paint.NET Discussion and Questions

    Posted

    Well, you can cut out the body from the image and put it on its own layer, too.

    Theoretically yes but in practice, the boundaries between the body skin and the background is not so well defined, particularly in the presence of clothes. The "magic wand" often fails to discern between them and using the lasso is very tedious, prone to errors and the results look bad.

    There must be a better way.

    Thanks,

    Alex.

    How to do "fakes" in PDN?

    in Paint.NET Discussion and Questions

    Posted

    You can use the Conditional Hue/Saturation plugin

    Thanks, I'll look at it.

    or just leave the head on its own layer and monkey with the colors in the Adjustments menu.

    That will not work since I want the head (face) to stay the same and adjust the skin tone of the body (affecting the background as little as possible).

    Sparkle! Plugins (v2.6; Updated: 10/31/2007)

    in Plugins - Publishing ONLY!

    Posted

    Hi MadJik, thanks for your reply!

    You shouldn't use a transparent background but a black one!

    Add some white spots then test the effect.

    Read the first post for more info!

    Happy new decade

    I may be missing something but I don't remember anything in the 1st post regarding black background for the "Glitter" plugin.

    I am also a little confused about the need for a black background.

    Here is what I am trying to do:

    1. Take an image

    2. Add a layer (transparent background by default) and make it the active one

    3. Select an area in the new layer

    4. Randomly add white points in that selection using your "Stars" effect.

    5. Blow the points up using your "Glitter" effect.

    Using a black background on the layer will prevent the original image from showing.

    Thank you and a happy 2010 to you too.

    Evan's Effects (open source as of October 16, 2012)

    in Plugin Packs

    Posted

    Hi pyrochild, thank you for your reply.

    If your workflow depends on a certain plugin, you should check to make sure it's compatible before upgrading Paint.NET.

    Can you suggest how to do that? Does Rick publish a list of blocked plugins or is it "upgrade, find out plugins are blocked, uninstall, find the old version, install" dance?

    In nearly all cases, it will either be compatible or have an updated version that is, but if not, it's very unlikely that it will "not cause any problems in [your] scenario."

    I use the oct/quad plugin occasionally to "create" shadows. I have never experienced a PDN crash or any other instability. Unless the alleged problem only started manifesting itself in 3.5, in which case I stand corrected.

    If this is the case, it's an order of magnitude for the plugin's author to give you a private build with a changed version number to assist fixing the problem than you changing the version number yourself.

    So let's say I write a plugin that, for some reason, gets blocked in a subsequent version of PDN. Since I cannot recreate the issue, I advertise that a "beta" build is available for those that want it (for error submission purposes or whatever). The end result is similar to what I suggested (in that it allows the user to load the plugin if they want to) except it provides less flexibility and more work on the user's part (renaming the DLL to make it load / not load, explicitly contacting the author, etc.)

    I can't do that, beyond what Simon and I have already told you.

    Fair enough.

    I understand that Evan has a new version out which I'll get the next time I have time for my PDN-related activities.

    However, I still believe that, in the general case, my suggestion merits consideration.

    Best regards,

    Alex.

    Evan's Effects (open source as of October 16, 2012)

    in Plugin Packs

    Posted

    Pyrochild doesn't block the plugins, so if you want to discuss it you should email Rick Brewster.

    1. Pyrochild implied that he knew how to override the block so I asked him to share the information. Surely it is a legitimate request.

    2. I prefer a public discussion to private emails. I suspect Rick will also prefer a single public discussion to potentially a multitude of emails.

    The only way you can override the block is to disassemble the plugin and change the version number.

    I suspect that would only work for unsigned assemblies.

    Evan's Effects (open source as of October 16, 2012)

    in Plugin Packs

    Posted

    Paint.NET has a blacklist of plugins that are problematic, included, etc.

    That doesn't look like the best way to address the problem to me. I would much prefer a solution that would allow me to choose whether to load the "problematic" plugin or not on a case-by-case basis.

    The reasons are twofold:

    1. If I come to depend on a plug-in in my workflow and it does not cause any problems in my scenarios, why should I be locked out of it?

    2. If the plugin *does* cause problems in my scenarios, but its author cannot reproduce them, I now cannot help him debug the problem.

    This is what I would suggest:

    Option 1: pop up a dialog on startup with the names of all the "banned" plugins and a set of options for each:

    (*) Ignore ( ) Load ( ) Permanently delete

    Option 2: add a command-line argument like:

    /forceload=

    You can override it by changing the version number of the Assembly, if you know how to do that. That doesn't necessarily mean the plugin will work, however. It will still have whatever problem made Rick decide to block it in the first place. In other words, override the block list is possible, but not recommended.

    I understand that but I would still appreciate if you told me how to override the block.

    Thanks,

    Alex.

×
×
  • Create New...