Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

OLE.CellImage slow on Windows 10

edited September 2019 in SRP EditTable Control
If you have a grid and then make a call to:
Set_Property(OLECtrlEntID, "OLE.CellImage[field; record]", StringValue)
where StringValue is a path to an image, and field and record are whatever, the set property is really slow...it can take up to 10 seconds to complete.

Points:
  1. Happens on windows 10 but not windows 7.
  2. Only happens the first time you call it, subsequent calls (for different rows) are fast.

Comments

  • The version we are using is 3.1.0. I know it's out of date, and your first suggestion will be to update lol but that's not possible at the moment.
  • edited September 2019
    The current version is 4.1.3. Even if it was still a bug, it would be fixed for 4.1.4. Thus, your inability to upgrade puts me in an awkward position. Is this a particularly large image?
  • edited September 2019
    hi, no it's not a large image. Ok i will try to get the team to upgrade, and we will see if that fixes it.

    Thanks
  • In the meantime, if it's a large (ish) file, feel free to send it to me to test. That way, if it's still a problem in the current version, I can have a fix ready.
  • @josh (and anybody else monitoring this thread), a helpful bit of advice when you encounter potential problems but you know your control is not current is to simply download the latest control from our product website and register it locally for your machine. This way you can run the same code but only you will be impacted by the upgrade to the control. This way you can easily determine if upgrading will fix the problem without having to do a full roll-out. (This does assume you are developing on a local workstation rather than a shared terminal server.)
  • hi, ok we did upgrade to 4.13 and it's still happening.
  • I would be helpful if you could send us the image you are using just so we can compare apples to apples. Feel free to email it to support@srpcs.com.
  • hi, this is the image:


  • In my test, the image loaded so quickly it was unmeasurable. I'm running Windows 10. I think there needs to be deeper analysis to see what could be at play here. What are the machine specs? Is it a virtual machine? Have you tried this on other Window 10 machines? What is your specific SRP EditTable configuration?
  • ok so it's more complicated than I though. Let me try to make a minimal working example.

    thanks
  • I had mixed results


  • yours is fast
  • but measurable.
  • and on a local machine. Not sure if you're testing over a network.
  • yeah it's over a network

    Both the .ocx file and the image are not on the user's computer.
  • but yeah don't worry too much about it, it's not a big deal, it's just something I noticed. I will try to get a small example when i have time.
  • Worried? Nope.
    Curious? Always.
  • I can't say this will have an impact on performance, but OCX files are recommended to be installed on local workstations.
  • edited September 2019
    yeah i know, i read your doco. But that's how our system was setup. It's not too late the change, let's see if we can change it.
  • Fair enough...but if your problems are the result of network latency due to client controls running from a network share then we can't really help you with the consequences. :)
  • I'm inclined to believe, however, this is not a network latency issue but something specific to your Windows 10 builds.
  • Well, we are having a lot of issues with windows 10. For example, oi randomly crashes for people with windows 10. I have no idea why it's happening.

    At first i thought it was because we were using an outdated version of your controls, but we upgraded for some users, and they still get the crash.

    Maybe it's because we not using the latest version of OI....
  • What kind of Windows crashes are you getting or what does the Windows Error Log report as the nature of the crash?
  • edited September 2019
    The errors vary,but today they've looked like this:

    Faulting application name: OINSIGHT.exe, version: 9.4.4.0, time stamp: 0x5c067fe2
    Faulting module name: SRPControls.ocx, version: 3.1.0.0, time stamp: 0x51c9cd97
    Exception code: 0xc0000005
    Fault offset: 0x0046d88c
    Faulting process id: 0x%9
    Faulting application start time: 0x%10
    Faulting application path: %11
    Faulting module path: %12
    Report Id: %13
    Faulting package full name: %14
    Faulting package-relative application ID: %15



    Fault bucket 1491061437138130633, type 1
    Event Name: APPCRASH
    Response: Not available
    Cab Id: 0

    Problem signature:
    P1: OINSIGHT.exe
    P2: 9.4.4.0
    P3: 5c067fe2
    P4: SRPControls.ocx
    P5: 3.1.0.0
    P6: 51c9cd97
    P7: c0000005
    P8: 0046d88c
    P9:

  • @josh, this was what I was wondering. We have discovered that this type of crash is often associated with OLE controls that are being loaded from a network share...which is why we've been pushing hard to have people store and register the OCX files locally.

    However, there have been some older versions of the SRPControls.ocx which cause crashes for various internal reasons. We've fixed all of the ones reported to us that were reproducible. Please let us know if you continue to experience crashes after you have upgraded and after you have registered the control locally. We will definitely want to fix anything that we can isolate as a problem within the control itself.
  • edited September 2019
    Hi,

    I think you'r re right. I've been thinking the same thing.

    Every since I upgrade to the latest OCX, we haven't seen the above error message anymore. But we are still seeing an error message, which looks like this:

    Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program Openinsight because of this error.

  • edited September 2019
    I upgraded the 5 users who use windows 10 to the latest OCX, and I put it on their hard drives. So maybe that's why they don't get this error anymore, and not that the OCX is the latest.

    Anyway, i think that OI also sometimes crashes when the users open the ole ie control. Perhaps that is also on the network rather than the user's computer. I need to find it in the registry:
    shell.explorer.2
  • ok, the dll is called ieframe.dll and it's on the user's computer, so it's not that...
  • edited September 2019
    I think it's fixed now. Problem was that the the windows 10 workstations were losing connection to the network share that OI is on. Which was happening due to a group policy update (https://www.qdoscc.com/blog/following-windows-10-upgrade-mapped-drives-disconnect-briefly).

    It's weird that upon losing connection to the shared drive, OI doesn't crash. It seems to only crash under the following scenario:

    1. Open OI.
    2. Open a form.
    3. Lose connection to where OI is located.
    4. The form opened in step 2 is removed from the cache. Not sure on the specifics about this, but OI seems to cache forms (i.e., they are still usable after losing connection to the network share if they were opened before the loss of connection). Of course, if the form does data access, this won't work, but anything not involving data access works.
    5. Try to open the form opened in step 2. OI crashes.

    Also, not sure if it's any form or only forms that have the internet explorer embedded active x control. Users mostly complained about the form with the IE active x control, but I think it crashed for me once for a different form.

    But I still need to check why the set_property for adding an image to a cell is slow.
Sign In or Register to comment.