Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
OLE.TitleList
Everything gets stuck into the first column heading, see screenshot.
The column header is set using the following where Col_Text is a @VM delimited list.
Call Set_Property(Obj,"OLE.TitleList",Col_Text)
In the below screenshot, the user had somehow created (not sure how) a table with 2305 columns most of which are blank. I don't think the issue is with the number of columns.
![](https://forum.srpcs.com/uploads/editor/0l/7agt8r7sbwe9.png)
I can not reproduce this on my machine with the same data, some it must be some issue with how it's installed on the client's computer.
They are using OI installed on a server and running from a client.
Any ideas what might cause TitleList to fail like this?
The column header is set using the following where Col_Text is a @VM delimited list.
Call Set_Property(Obj,"OLE.TitleList",Col_Text)
In the below screenshot, the user had somehow created (not sure how) a table with 2305 columns most of which are blank. I don't think the issue is with the number of columns.
![](https://forum.srpcs.com/uploads/editor/0l/7agt8r7sbwe9.png)
I can not reproduce this on my machine with the same data, some it must be some issue with how it's installed on the client's computer.
They are using OI installed on a server and running from a client.
Any ideas what might cause TitleList to fail like this?
Comments
The problem is that I'm not sure why this would happen. The UTF8 flag in OI's Application Settings usually does not affect how OI converts to Unicode before passing strings to OLE controls. I do know that the conversion logic OI uses is inside their UTF8.dll. Perhaps it's corrupted? This would explain why only this one system is going bonkers.
BTW SRPControls.ocx is installed into $sysdir on the client using NSIS.
At least two of the client machines are exhibiting this (we only checked two), however, the UTF8.DLL is on the server unless OI client software installs it on the client?
We are going to try a re-install.
Thanks for the suggestion, I'm thinking it has to be corruption. Hopefully, I re-install fixes it.
Everything works if OI is run on the server. It fails when run from a client.
If I use Call Set_Property(Obj,"OLE.TitleList",Col_Text) to put a @VM delimited list of say 10 values into an edittable it puts all the text including @VM into the first column. When I then use Call Col_Text = Get_Property(Obj,"OLE.TitleList") to get that same data back I get a @VM delimited list of data that is correct except that it has 9 extra null @VM delimited values at the end. So the data is coming back from the first column is @VM delimited text.
What is the next step to figure out what is happening?
We have a customer that needs help.
Can you elaborate? What kind of server? What kind of client? What differences do you know exist between the two?
Does it happen to every table? Every control?
There is something about this machine. Parsing VMs is so trivial that I am convinced there is something totally unique about this client. Perhaps there is a strange language setting in the OS that is messing with how OI converts to Unicode or how Windows is interpreting it?
This has been working for years and suddenly on Monday stopped working. I have not extensively tested, but SRP popup and edittable are affected.
What is interesting is if I use Set_Property followed by Get_Property the string I get back is all @VM delimited, with the correct text, all be it with extra @VMs. The extra @VM values are from the blank columns.
I'm not sure what else to suggest other than to find out from your client's IT team what changed over the weekend. Windows update? Server update?
Thank you.
We are using SRPs edittable and when I set the Column headings using OLE.TitleList everything gets stuck into the first column heading. Delimiters and all, the OLE control is expecting a @VM delimited list and should set each column heading to one of the @VM delimited values.
The column header is set using the following where Col_Text is a @VM delimited list.
Call Set_Property(Obj,"OLE.TitleList",Col_Text)
I can not reproduce this on my machine with the same data, so it must be some issue with how it's installed on the client's computer.
We tried re-installing everything and that did not work, the same behavior is seen.
They are using OI installed on a server and running from a client. If they run the same installation using the same data on the server and using the same user credentials by using remote desktop everything works. It only fails when run from the client using \\Server\Share\OINSight.exe. OI client software and SRP control is installed on the client computer.
I have been talking with SRP and they think it might have something to do with UTF8.DLL and the conversion that takes place into Unicode prior to passing the data to the OLE control.
Does UTF8.DLL rely on some OS settings to determine how to encode OI delimiters?
This has been working for years and stopped working at the beginning of the week. The user says nothing has changed but clearly something obviously has.
Any other ideas?
Str_Unicode does not seem to be in the help file. Do you know what parameters I pass?
Thank you.
Subroutine Test_Unicode(Null)
**********************************************************************
* Write Unicode test string to Text.txt in root of Tactic install *
* visim jrv 11-6-19 *
**********************************************************************
Declare Function Str_Unicode
CurrentDir = Drive()
If CurrentDir[Len(CurrentDir),1] = "\" Then
CurrentDir = CurrentDir[1, Len(CurrentDir)-1]
End
UnicodeString = Str_Unicode("Test1":@VM:"Test2":@VM:"Test3")
Test_File = CurrentDir:"\Text.txt"
OSWrite UnicodeString On Test_File
Return
MyUnicodeVar = Str_Unicode(MyVar)
There it is. VMs are being converted to 00FD instead of F0FD.Nevermind. I read it backwards. The VM is in fact F0FD. In Unicodes, the bytes are in reverse order for each character.
https://www.revelation.com/revweb/oecgi4p.php/O4W_RUN_REPORT?RPTTYPE=LY&NOSELECT=&REPORTID=WORKS_BOARD_2#/section/breadcrumb/DATATABLE/Select
I have sent the code to one of my co-workers and they are going to get them to run the code on the server and on one of the problematic clients. It may take a few days as they have to get IT people involved. As soon as I hear back, I'll post the results here.
Ah ha! - Thanks Kevin :)