Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
EditTable and Row discrepency in InitMenu
Hello All!
I will try to keep this concise.
My issue is that I have a List that has 93 entries. I set that LIST to a OI EditTable.
The EditTable displays 93 lines. All good so far.
I then apply a OnComboClick filter on a Subclassed EDL that basically takes that List and recalculates it to 14 lines.
[This filtering is basically just taking thge List and, if a certain value matches, adding it to a new List that gets set to the Control.]
I then set that new List back to the same EditTable.
The EditTable displays 14 lines . Excellent!
However, InitMenu wont work for the last line (or with other 'filter' values applied, sometimes more than a few of the last lines)
Debugging shows me that previous lines are actually coming through with a incorrect Row value.
e.g. Right-click on Row 13 is passing into InitMenu as Row 14. Row 1 comes in as Row 1 though. The later rows are not working because, I am guessing, their 'Row' exceeds the actual row count in the table.
So my question is why would this be the case?
I seem to recall stumbling across something similar several years ago but the exact circumstance eludes me ....
EDIT.
I should add that the table has been Trimmed:
ETMethod(@WINDOW:".MY_TABLE", "TRIM", 0)
Amd just before applying the new filered list I tried (courtesy of the Sprezzatura EditTable Cookbook for clearing a table when dealing with large arrays) :
SendMessage(Get_Property( @Window:".MY_TABLE", "HANDLE" ), 1025, 0, 0 )
I will try to keep this concise.
My issue is that I have a List that has 93 entries. I set that LIST to a OI EditTable.
The EditTable displays 93 lines. All good so far.
I then apply a OnComboClick filter on a Subclassed EDL that basically takes that List and recalculates it to 14 lines.
[This filtering is basically just taking thge List and, if a certain value matches, adding it to a new List that gets set to the Control.]
I then set that new List back to the same EditTable.
The EditTable displays 14 lines . Excellent!
However, InitMenu wont work for the last line (or with other 'filter' values applied, sometimes more than a few of the last lines)
Debugging shows me that previous lines are actually coming through with a incorrect Row value.
e.g. Right-click on Row 13 is passing into InitMenu as Row 14. Row 1 comes in as Row 1 though. The later rows are not working because, I am guessing, their 'Row' exceeds the actual row count in the table.
So my question is why would this be the case?
I seem to recall stumbling across something similar several years ago but the exact circumstance eludes me ....
EDIT.
I should add that the table has been Trimmed:
ETMethod(@WINDOW:".MY_TABLE", "TRIM", 0)
Amd just before applying the new filered list I tried (courtesy of the Sprezzatura EditTable Cookbook for clearing a table when dealing with large arrays) :
SendMessage(Get_Property( @Window:".MY_TABLE", "HANDLE" ), 1025, 0, 0 )
Comments
I started to some reseach, thinking that I must be missing something too to get that response Don.
Since I cant find what I am looking for (INITMENU) in Oi Docs I am starting to beleive we have some custom Promoted Events happening!
I honestly thought INITMENU was just standard OI. Never had a reason before now to think otherwise....
You might have no idea what I am talking about for a reason!
I am trying to fire my custom event (INITMENU) when the user right-clicks on an EditTable. So far, I can get the promoted create event to work (setting up QUALIFY_EVENT to detect right click and redirect to an event), and can select the correct cell within the EditTable, but not execute my custom event.
Cheers,
Andrew Matthews
iTMS Software
Well that certainly lines up with what I an now thinking!!!!
Not sure who Andrew was but since he worked for the company's predecessor (iTMS), I will take that as confirmation.
Since that was LONG before my time I will just put it down to the Stone Tablet documentation being lost over the eons....
Leave it with me since it is clearly not OI anymore. Thanks Don & Barry for the responses.
I learned something new today about my own product!!
Debugging shows me that previous lines are actually coming through with a incorrect Row value.
When I read that, I assume that you are either in a routine or an event called InitMenu and it seems as if Row is an argument being passed in. Is this accurate?
If so, then what exactly is InitMenu (i.e., routine or event)? What is in the call stack when it gets called? This is the bit of sandwich filler (or vegemite) between two slices of bread that I'm missing.
I understood (without understanding), which is why I then started to doubt myself. The "What the heck are you talking about" led me to believe I didn't know what I was talking about.
At the original time of posting I was of the belief that OI was passing through Row to an OI Event called InitMenu on a right mouse click on the EditTable and any issue was located in the 'black box' of Revelation code.
After your reply, I pretty quickly started to consider exactly what Barry also pointed out. The InitMenu Event I was debugging in the Form's Commuter isn't standard OI fare but rather a Custom Event. This InitMenu Event has (Col,Row) passed in as parameters.
As for the Call Stack, I hadn't even looked initially...so confident was I that OI was doing something weird.
Here is the call stack (for the record):
So it looks like we are using a localised version of SRP's Context_Menu_Manager.
In the Check_For_Menu routine, we intercept CtrlType EQ "EDITTABLE" and do a Send_Event to InitMenu instead, passing through the Col and Row from that routine. The Col and Row is determined via a function you wrote a quarter-century ago Don, Cursor_Position!
I havent had a chance to trace it through yet, but at least I have moved my starting point to where it should be!
I was trying to work out where the INITMENU Event was defined (I surprisingly have never had to actually created my own Event yet!)
I found my way to the Event Designer. I couldn't see any INITMENU on the EditTables but figured it was maybe WinMSG related so pressed the Generate Promoted Code button on that option.
I thought would create a code snipet but I quickly realised it was doing more than that and stopped it.
I did a quick Deploy - "Changed since" and could see it created a Procedure and changed and compiled about half a dozen forms.
Searching for that new procedure name I saw quite a number of SYS-orientated entries.
So what damage have I caused? If the answer is not benign, how easy is it to rollback?
I think you can change the Enforce flag to No. I would also look for and delete the AppID*WINMSG.EDITTABLE.OIWIN* record in SYSREPOSEVENTEXES.
Then restart OI and recompile those forms. That should restore them. The procedure that was created is likely the stub generated where you can add your own logic for promoted WINMSG calls. You can delete that too if you want.
I would say that would teach me to not play around but it won't. I just need to be more cautious of what environment I am in at the time!
can you show the command line for that. I think you might be going down the wrong path.
I followed your instructions. All the below entries seem clear now and the 8 forms recompiled and working.
Thanks for the assist. All that for something I was chasing up on the side 'out of curiosity'
@BarryStevens, here is the code doing the actual lifting. It is a localised and modified version of the Frameworks version of the Context_Menu_Manager:
It is definately this bit of code. I haven't had a chance to trace this bit yet. For my problem lines, the Col and Row returned from the Cursor_position call to the Position variable are both 0. It has the x and y co-ordinates though.
My non problem lines return Col and Row fine.
This line also confuses me because your original post notes that the problem is that the row position is offset by 1, not that it is reset to 0.
Yes, I meant xPos and yPos (positions 3 and 4)
I think I misled everyone when I said "My non problem lines return Col and Row fine"
More accurately, "My non problem lines return Col and Row non-zero values".
The xPos and yPos values should always be correct. Those are coming from a Windows API.
The Col and Row are calculated because older versions of OI don't have a way to convert screen position to cell position.
If you look at the code you'll see that the logic makes assumptions about the height of the header, the height of a row, and the width of a gridline. Using these values, the logic then adds these numbers together and begins to add one row height at a time until the total exceeds the value of yPos. It then assumes that the last row count that did not exceed the value of yPos must be the row position where the mouse cursor is.
Since your row position is off by one, I am curious if it is only slightly off. For instance, is it off by one for the entire height of the row or does it correct itself if you move the cursor closer to the top of the row? Similarly, what about the other rows? Are these also off by one? You said row 1 is never off, but what about 2, 3, 4, etc.?
So first things first. I am not sure what you mean by 'older versions' bacuse pretty much anything non-10 could probably fall under that umbrella!!! Is there a better way in , say 9.4.x, to accomplish that?
I did notice the assumtpions about height etc. There is a note about programtaically setting those in the future. I tried to manually adjust the row height and for a second I thought that worked but it alas it did not (I think maybe it was better but not foolproof). I couldn't actually see how to grab the row height via Styles, Font, Orig_Struct or like properties. I can see how I could get colwidth and headerheight though.
As for the only 'slightly off', the asnwer is yes, sort of. In a small set of 7 values it is in row 4 it loses itself. Top of the Row = 4. Bottom of the row = 5. However, this is cumulative. I also tried with a filtered set of 66 lines and line 66 was thinking it was line 70! At least, because it was still in the 'Box', it was returning non-zero values. As I have noted, sometimes that is not the case. That is where I was getting 0 returns for Col and Row I think.
So, in summary, it seems to start OK (within tolerance anyway) but then progressively goes out... but not consistently at the same points (that I have been able to prove yet anyway!).
I was referring to the versions of OI that were available 25 years ago, so that would have primarily been 2.x and 3.x (16bit versions of OI) and 4.x (the first 32bit version of OI). Newer 32bit versions, especially 9.x, have exposed more of the EditTable API so I think a utility like this could definitely be refactored.
I think your observations validate my theory, but I'm not convinced my theory explains all that you are observing. I would have to dig deeper to be certain.
I think what you are saying is right but I have not been able to ascertain the magic 'formula' of it going out (after x records then y pixels are out)
Like I said, I have even seen where the Pos is outside the Box (hence it returns 0 Col and Row) so I am not even certain that I am fully trusting of the original X,Y Co-ordinates (or maybe it is the Box?)
I am also confused why this hasnt been an issue as many of our EditTables would use this custom InitMenu and if it was passing in the wrong row value then the 'key' column would be incorrect as well for those where it worked. I would have thought this to be a much bigger issue so I was leaning towards why is this just showing up now?
I did try to use an older SRP Controls (to take away the Ribbon / Frame work that was recently done) to see if the location in the Frame was being misrepresented. That didn't appear to be the case.
I still have more question that answers so far!