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 / C++ / MFC
  4. Strange CListBox Behavior

Strange CListBox Behavior

Scheduled Pinned Locked Moved C / C++ / MFC
helptutorialquestion
13 Posts 3 Posters 0 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.
  • L Lost User

    I have edited your question so all the information is visble. In future please use <pre> tags around code blocks.

    J Offline
    J Offline
    Jochen Arndt
    wrote on last edited by
    #4

    Thank you. I was just going to post a message that he should do that.

    1 Reply Last reply
    0
    • J Jochen Arndt

      If you always get the same data value regardless of the index, all items may have the same data value. So check the code portions that set the item data of the right list box.

      W Offline
      W Offline
      wdolson
      wrote on last edited by
      #5

      Sorry about the formatting, it was the first time I posted anything with code here. The value is not always the same, it's whatever is last on the list. If the right list has the following strings: "1" "2" "4" "7" "10" "11" Selecting "2" and clicking on the move left button will get the "11" and it will be moved to the left. If you then select the "2" again (or anything else on the list) and click on the move left button, the "10" will be selected and moved. What gets selected is whatever is last on the list. The code for moving from the left box to the right is identical except for the control name and selecting the "2" would actually fetch the "2" from index 1 and move it. The index fetched in both cases is correct. What isn't working is the code that gets the value for the index. I'm completely baffled. The two are coded the same.

      L J 2 Replies Last reply
      0
      • W wdolson

        Sorry about the formatting, it was the first time I posted anything with code here. The value is not always the same, it's whatever is last on the list. If the right list has the following strings: "1" "2" "4" "7" "10" "11" Selecting "2" and clicking on the move left button will get the "11" and it will be moved to the left. If you then select the "2" again (or anything else on the list) and click on the move left button, the "10" will be selected and moved. What gets selected is whatever is last on the list. The code for moving from the left box to the right is identical except for the control name and selecting the "2" would actually fetch the "2" from index 1 and move it. The index fetched in both cases is correct. What isn't working is the code that gets the value for the index. I'm completely baffled. The two are coded the same.

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #6

        Why are you casting string values to floats in your code? You should use your debugger to step through the code and see exactly what values are being stored in your array (and why is it declared with two int fields?), and how they are matching the items in the lists.

        W 1 Reply Last reply
        0
        • L Lost User

          Why are you casting string values to floats in your code? You should use your debugger to step through the code and see exactly what values are being stored in your array (and why is it declared with two int fields?), and how they are matching the items in the lists.

          W Offline
          W Offline
          wdolson
          wrote on last edited by
          #7

          SetItemData allows you to associate a 32 bit value with the index and GetitemData retrieves that data. When I do the AddString to put the strings in the list box, if successful I load a float value associated with the string with SetItemData. When retrieved it has to be cast back to float because GetItemData returns a DWORD. In this particular dialog the data is stored as a float, but is always an integer. The program does this because the same data space can be used for float values too, but if you're in this dialog, the data will always be integers stored as floats.

          1 Reply Last reply
          0
          • W wdolson

            Sorry about the formatting, it was the first time I posted anything with code here. The value is not always the same, it's whatever is last on the list. If the right list has the following strings: "1" "2" "4" "7" "10" "11" Selecting "2" and clicking on the move left button will get the "11" and it will be moved to the left. If you then select the "2" again (or anything else on the list) and click on the move left button, the "10" will be selected and moved. What gets selected is whatever is last on the list. The code for moving from the left box to the right is identical except for the control name and selecting the "2" would actually fetch the "2" from index 1 and move it. The index fetched in both cases is correct. What isn't working is the code that gets the value for the index. I'm completely baffled. The two are coded the same.

            J Offline
            J Offline
            Jochen Arndt
            wrote on last edited by
            #8

            You may debug your application and inspect all list items (index, string, value); optionally also using TRACE statements. But you should also show the code used to add items to the right list box because the source may be there (I guess that it is empty upon program start). When the list box has sorting enabled, the order of items shown on screen does not correspond to the indexes. So when adding an item, it should look like:

            int ndx = m_lstRight.AddString(strItem);
            m_lstRight.SetItemData(ndx, val);

            W 1 Reply Last reply
            0
            • J Jochen Arndt

              You may debug your application and inspect all list items (index, string, value); optionally also using TRACE statements. But you should also show the code used to add items to the right list box because the source may be there (I guess that it is empty upon program start). When the list box has sorting enabled, the order of items shown on screen does not correspond to the indexes. So when adding an item, it should look like:

              int ndx = m_lstRight.AddString(strItem);
              m_lstRight.SetItemData(ndx, val);

              W Offline
              W Offline
              wdolson
              wrote on last edited by
              #9

              The box isn't sorted, but that's how I assign data to the list box:

              int idx;
              idx = m_lstRight.AddString(szStr);
              if(idx = LB_ERR)
              {
              m_lstRight.SetItemData(idx, (DWORD)val);
              }

              I looked at the data being assigned to the list box and everything was fine. I haven't figured out how to look at the data in a CListBox. I put a watch on it, but I didn't see where the data was stored when I inspected the control.

              J 1 Reply Last reply
              0
              • W wdolson

                The box isn't sorted, but that's how I assign data to the list box:

                int idx;
                idx = m_lstRight.AddString(szStr);
                if(idx = LB_ERR)
                {
                m_lstRight.SetItemData(idx, (DWORD)val);
                }

                I looked at the data being assigned to the list box and everything was fine. I haven't figured out how to look at the data in a CListBox. I put a watch on it, but I didn't see where the data was stored when I inspected the control.

                J Offline
                J Offline
                Jochen Arndt
                wrote on last edited by
                #10

                That will set idx to LB_ERR. I don't know what happens with the SetItemData call then but there are two options: It will fail or set the value of the last item in the list. It should be:

                if(idx != LB_ERR)
                {
                m_lstRight.SetItemData(idx, (DWORD)val);
                }

                When SetItemData fails when passing LB_ERR (which is most probable), you can remove the if condition. [EDIT] Just a tip for such conditions: Exchange the expressions. If you would have used

                if(LB_ERR = idx)

                you would have got a compiler error and noticed your fault.

                W 1 Reply Last reply
                0
                • J Jochen Arndt

                  That will set idx to LB_ERR. I don't know what happens with the SetItemData call then but there are two options: It will fail or set the value of the last item in the list. It should be:

                  if(idx != LB_ERR)
                  {
                  m_lstRight.SetItemData(idx, (DWORD)val);
                  }

                  When SetItemData fails when passing LB_ERR (which is most probable), you can remove the if condition. [EDIT] Just a tip for such conditions: Exchange the expressions. If you would have used

                  if(LB_ERR = idx)

                  you would have got a compiler error and noticed your fault.

                  W Offline
                  W Offline
                  wdolson
                  wrote on last edited by
                  #11

                  That's the problem! For some reason when setting the left box, the exclamation point was in there, but it was missing from the setting of the right box. That usually flags an warning on compile. I wonder why it wasn't. It appears SetItemData is doing something though. The value returned with GetItemData is always the last value on the list. The list redraws after a move, so all the items were probably getting set to the last value for some reason I don't understand. It works now. I think I need glasses... Thanks!

                  J L 2 Replies Last reply
                  0
                  • W wdolson

                    That's the problem! For some reason when setting the left box, the exclamation point was in there, but it was missing from the setting of the right box. That usually flags an warning on compile. I wonder why it wasn't. It appears SetItemData is doing something though. The value returned with GetItemData is always the last value on the list. The list redraws after a move, so all the items were probably getting set to the last value for some reason I don't understand. It works now. I think I need glasses... Thanks!

                    J Offline
                    J Offline
                    Jochen Arndt
                    wrote on last edited by
                    #12

                    Fine to hear that the problem is solved. If you use the tip from my edited previous post you will avoid such errors in the future. I'm using that since some years and it probably saved me a lot of time. According to your description it seems that SetItemData is setting the value of the last item when passing LB_ERR (like with other list box function when passing -1).

                    1 Reply Last reply
                    0
                    • W wdolson

                      That's the problem! For some reason when setting the left box, the exclamation point was in there, but it was missing from the setting of the right box. That usually flags an warning on compile. I wonder why it wasn't. It appears SetItemData is doing something though. The value returned with GetItemData is always the last value on the list. The list redraws after a move, so all the items were probably getting set to the last value for some reason I don't understand. It works now. I think I need glasses... Thanks!

                      L Offline
                      L Offline
                      Lost User
                      wrote on last edited by
                      #13

                      wdolson wrote:

                      usually flags an warning on compile.

                      It is a valid expression in C++, but newer versions of the compiler do, I think, give a warning about it.

                      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