›
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

jimvaughanjimvaughan
in SRP EditTable Control
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.



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?
«1

Comments

  • KevinFournierKevinFournier
    edited November 2019
    The only thing I can think of is that, somehow, the value marks are not true value marks when the Edit Table parses the Col_Text. OI has to convert all strings to Unicode when passing them to OLE controls, including delimiters. Value marks are Char 0xFD in OI but get converted to 0xF0FD before being passed to our controls. If something is causing those delimiters to get converted to something like 0x00FD instead, then the TitleList property will not parse the titles correctly.

    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.
  • jimvaughanjimvaughan
    Now the user is saying that the popup control (we allow the user to hover and popup information) is popping up but is blank. Any ideas?

    BTW SRPControls.ocx is installed into $sysdir on the client using NSIS.
  • KevinFournierKevinFournier
    I'm thinking that OI is not converting to Unicode correctly. Once that goes wrong, there's no way for the controls to get anything right.
  • jimvaughanjimvaughan
    So they must have changed something in how the client (or maybe server) is configured? Or as you say something is corrupt.

    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.
  • MattCrozierMattCrozier
    Maybe SetNoOfDelimiters() is being called, or the SYSTEM.NO_OF_DELIMITERS property is being set, with a low value somewhere??
  • jimvaughanjimvaughan
    Just checked, no we do not call SetNoOfDelimiters or set that property.

    Thanks for the suggestion, I'm thinking it has to be corruption. Hopefully, I re-install fixes it.
  • jimvaughanjimvaughan
    Re-install did not fix the problem, but I do have some more information.

    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.

  • KevinFournierKevinFournier
    Everything works if OI is run on the server. It fails when run from a client.


    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?

    What is the next step to figure out what is happening?


    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?
  • jimvaughanjimvaughan
    edited November 2019
    The server is 2012 server I think. It fails from all different client machines, we have tested on. All client machines are Windows (not sure what OS). If the user uses Remote Desktop to remote into the server everything works as expected. Only when run from a \\server\Share\Oinsight.exe from a client does it fail.

    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.
  • KevinFournierKevinFournier
    The extra VMs are expected. The fact that you are getting true-blue VMs back from the property really confirms my suspicions that OI is not encoding/decoding VMs as the control expects. Perhaps run a test routine on their system that passes a similar structure to Str_Unicode and then write the results to a file. Send it to me (or just examine it yourself) to see what two-byte sequences the string is converted to. VMs need to be 0xF0FD in order for the SRP ActiveX Controls to recognize them.

    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?
  • KevinFournierKevinFournier
    If you haven't already, I'd reach out to Revelation to find out if UTF8.DLL relies on some OS setting to determine how to encode OI delimiters.
  • jimvaughanjimvaughan
    OK, I will do both of these. I let you know the results.

    Thank you.
  • jimvaughanjimvaughan
    edited November 2019
    FYI I posted the following on the OI forum

    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?
  • jimvaughanjimvaughan
    Kevin,

    Str_Unicode does not seem to be in the help file. Do you know what parameters I pass?

    Thank you.
  • BarryStevensBarryStevens
    Jim, I think it is a parameter in one of the Srp util string type commands
  • BarryStevensBarryStevens
    Try the tooltip in Srp editor
  • MattCrozierMattCrozier
    Both Str_Unicode() and ANSI_Unicode() are prototyped for the CRevExt DLL (so part of OI), but I'm not sure what the difference between the two is? Both seem to convert ANSI strings to Unicode.
  • jimvaughanjimvaughan
    edited November 2019
    FYI

    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
  • KevinFournierKevinFournier
    Sadly, it's not documented. Here's a sample:

    MyUnicodeVar = Str_Unicode(MyVar)
  • jimvaughanjimvaughan
    This is what I get on my system, I will let you know what they see.

  • KevinFournierKevinFournier
    edited November 2019
    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.
  • KevinFournierKevinFournier
    @MattCrozier, Str_Unicode is more like a macro in that it "becomes" Ansi_Unicode if the UTF8 flag is off and UTF8_Unicode if the UTF8 flag is on.
  • jimvaughanjimvaughan
    Yes, this is on my system which works fine.
  • KevinFournierKevinFournier
    If you can run this same code on your broken client machines, it would be informative to see if you get different results.
  • DonBakkeDonBakke
    @jimvaughan you mentioned that you posted a question on the Revelation forum. What forum are you referring to specifically?
  • jimvaughanjimvaughan
    The Works Forum.

    https://www.revelation.com/revweb/oecgi4p.php/O4W_RUN_REPORT?RPTTYPE=LY&NOSELECT=&REPORTID=WORKS_BOARD_2#/section/breadcrumb/DATATABLE/Select
  • jimvaughanjimvaughan
    Kevin,
    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.
  • MattCrozierMattCrozier
    Str_Unicode is more like a macro in that it "becomes" Ansi_Unicode if the UTF8 flag is off and UTF8_Unicode if the UTF8 flag is on.

    Ah ha! - Thanks Kevin :)
  • BarryStevensBarryStevens
    @donbakke looks like Jim's post is only showing on 'last year by date' not 'all by date' (indexing still not right)
  • DonBakkeDonBakke
    @BarryStevens thanks. I didn't realize the Rev forums were back online. I never saw an email announcing this.
Sign In or Register to comment.