OLE.CellImage slow on Windows 10

josh

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.
   

josh

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.

KevinFournier

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?

josh

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

KevinFournier

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.

DonBakke

@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.)

josh

hi, ok we did upgrade to 4.13 and it's still happening.

DonBakke

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.

josh

hi, this is the image:

KevinFournier

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?

josh

ok so it's more complicated than I though. Let me try to make a minimal working example.

thanks

AusMarkB

I had mixed results

josh

yours is fast

AusMarkB

but measurable.

AusMarkB

and on a local machine. Not sure if you're testing over a network.

josh

yeah it's over a network

Both the .ocx file and the image are not on the user's computer.

josh

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.

AusMarkB

Worried? Nope.
Curious? Always.

DonBakke

I can't say this will have an impact on performance, but OCX files are recommended to be installed on local workstations.

josh

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.

DonBakke

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. :)

DonBakke

I'm inclined to believe, however, this is not a network latency issue but something specific to your Windows 10 builds.

josh

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....

DonBakke

What kind of Windows crashes are you getting or what does the Windows Error Log report as the nature of the crash?

josh

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:

DonBakke

@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.

josh

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.

josh

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

josh

ok, the dll is called ieframe.dll and it's on the user's computer, so it's not that...

josh

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.