Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. Error Creating Window Handle

Error Creating Window Handle

Scheduled Pinned Locked Moved C#
helpcssdata-structurestutorialquestion
6 Posts 3 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    jpwkeeper
    wrote on last edited by
    #1

    I'm having a problem where I run out of window handles, even though the number seems to be within the realm of the sane. What I'm doing is creating a scrollable list of bar charts. The bar charts are interactive, so what I did was make each bar a separate control. This made selecting, floating tooltips, and many other things very easy. They're built dynamically. I was very proud of this idea. Now, I have 100 bar charts, with 108 bars (in this case) each and say 12 other controls per chart (may be slightly less than that). That only amounts to 12,000 window handles, which even on 95/98 should be OK and I'm running XP Pro. I can't imagine that my main app window is using over 4,384 window handles. When I hit my AddRange, I run out of window handles and get "Error Creating Window Handle". I can't even do this with 50 charts. Any ideas on how to work around this without having to re-write my bar graph displays? Also, any idea on how spy on my application's window handle usage so I can determine exactly what I'm up against? John Woodard

    P 1 Reply Last reply
    0
    • J jpwkeeper

      I'm having a problem where I run out of window handles, even though the number seems to be within the realm of the sane. What I'm doing is creating a scrollable list of bar charts. The bar charts are interactive, so what I did was make each bar a separate control. This made selecting, floating tooltips, and many other things very easy. They're built dynamically. I was very proud of this idea. Now, I have 100 bar charts, with 108 bars (in this case) each and say 12 other controls per chart (may be slightly less than that). That only amounts to 12,000 window handles, which even on 95/98 should be OK and I'm running XP Pro. I can't imagine that my main app window is using over 4,384 window handles. When I hit my AddRange, I run out of window handles and get "Error Creating Window Handle". I can't even do this with 50 charts. Any ideas on how to work around this without having to re-write my bar graph displays? Also, any idea on how spy on my application's window handle usage so I can determine exactly what I'm up against? John Woodard

      P Offline
      P Offline
      perlmunger
      wrote on last edited by
      #2

      Can you provide some sample code and tell us what you're using to write this? I've built something very similar to what you describe but using GDI with C++. I had a resource leak problem once where I wasn't freeing my resources soon enough. After a while, the app just crapped out because it had maxed out the GDI object limit. The only way I knew to debug that was to add a column to the process tab in the Task Manager and watch to see when the GDI object count started getting out of control while stepping through the debugger. Not sure it's the same issue here, but it would help if you gave a little more detail. Thanks. -Matt ------------------------------------------ The 3 great virtues of a programmer: Laziness, Impatience, and Hubris. --Larry Wall

      L 1 Reply Last reply
      0
      • P perlmunger

        Can you provide some sample code and tell us what you're using to write this? I've built something very similar to what you describe but using GDI with C++. I had a resource leak problem once where I wasn't freeing my resources soon enough. After a while, the app just crapped out because it had maxed out the GDI object limit. The only way I knew to debug that was to add a column to the process tab in the Task Manager and watch to see when the GDI object count started getting out of control while stepping through the debugger. Not sure it's the same issue here, but it would help if you gave a little more detail. Thanks. -Matt ------------------------------------------ The 3 great virtues of a programmer: Laziness, Impatience, and Hubris. --Larry Wall

        L Offline
        L Offline
        leppie
        wrote on last edited by
        #3

        perlmunger wrote: I had a resource leak problem once where I wasn't freeing my resources soon enough. That sounds about right. :) ALLWAYS kleen up your mess :) MyDUMeter: a .NET DUMeter clone

        J 1 Reply Last reply
        0
        • L leppie

          perlmunger wrote: I had a resource leak problem once where I wasn't freeing my resources soon enough. That sounds about right. :) ALLWAYS kleen up your mess :) MyDUMeter: a .NET DUMeter clone

          J Offline
          J Offline
          jpwkeeper
          wrote on last edited by
          #4

          Being a C++ programmer I understand where you're coming from. I'm a C++ programmer as well. However, this is not C++, and it's not a leak. I can't easily post the code. First of all, this is managed code. This is further proven by the fact that if I switch to a smaller list after the problem has happened, I can continue to run. Second, it's not like it's happening due to repeated operations. I can run all day, so long as I don't have too many controls up at one time. The first time I graph 100 at a time I fail, but I can choose 20 different lists of 10 in sequence and I still work fine so long as I don't do it too fast (so the GC has time to catch up). What it appears to be is that I'm limited to 16384 window handles. if each control has a window handle, that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. This is almost certainly the problem. I changed it so that instead of a full-out control, each bar is defined by a helper class that renders it and the problem went away (obviously the helper class doesn't use a window handle, it just has the paint code). My question is, can I get around the 16K limitation (if that is indeed the limit)?

          L 2 Replies Last reply
          0
          • J jpwkeeper

            Being a C++ programmer I understand where you're coming from. I'm a C++ programmer as well. However, this is not C++, and it's not a leak. I can't easily post the code. First of all, this is managed code. This is further proven by the fact that if I switch to a smaller list after the problem has happened, I can continue to run. Second, it's not like it's happening due to repeated operations. I can run all day, so long as I don't have too many controls up at one time. The first time I graph 100 at a time I fail, but I can choose 20 different lists of 10 in sequence and I still work fine so long as I don't do it too fast (so the GC has time to catch up). What it appears to be is that I'm limited to 16384 window handles. if each control has a window handle, that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. This is almost certainly the problem. I changed it so that instead of a full-out control, each bar is defined by a helper class that renders it and the problem went away (obviously the helper class doesn't use a window handle, it just has the paint code). My question is, can I get around the 16K limitation (if that is indeed the limit)?

            L Offline
            L Offline
            leppie
            wrote on last edited by
            #5

            jpwkeeper wrote: that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. You mean all the "bars" are seperate controls? :eek: GDI is a must! I dont even wanna know how much memory this thing eats! ;P MyDUMeter: a .NET DUMeter clone

            1 Reply Last reply
            0
            • J jpwkeeper

              Being a C++ programmer I understand where you're coming from. I'm a C++ programmer as well. However, this is not C++, and it's not a leak. I can't easily post the code. First of all, this is managed code. This is further proven by the fact that if I switch to a smaller list after the problem has happened, I can continue to run. Second, it's not like it's happening due to repeated operations. I can run all day, so long as I don't have too many controls up at one time. The first time I graph 100 at a time I fail, but I can choose 20 different lists of 10 in sequence and I still work fine so long as I don't do it too fast (so the GC has time to catch up). What it appears to be is that I'm limited to 16384 window handles. if each control has a window handle, that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. This is almost certainly the problem. I changed it so that instead of a full-out control, each bar is defined by a helper class that renders it and the problem went away (obviously the helper class doesn't use a window handle, it just has the paint code). My question is, can I get around the 16K limitation (if that is indeed the limit)?

              L Offline
              L Offline
              leppie
              wrote on last edited by
              #6

              O yes, have a look at my MyDUMeter article. I do some "graphing" in there. Have a look at the ReportForm. Might be of some help. :) MyDUMeter: a .NET DUMeter clone

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups