LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Button/Boolean mouse hover not working on 64 Bit LabVIEW


@Zyga wrote:

This drives me mad. Can someone from NI update status on this issue? How can I release application which woks like this?
Is there a way to officially report a bug?


https://www.google.com/search?q=labview+bug+report

0 Kudos
Message 31 of 66
(4,303 Views)

@billko wrote:

You can release it as a 32-bit executable - if you don't need 64-bit memory space, and you either don't have dlls, or the dlls have 32-bit counterparts installed/included.


I need both. No 32-bit counterparts...

 

I actually agree that it is annoying, and that it's a bit quite on the blue side...

0 Kudos
Message 32 of 66
(4,302 Views)

Using 32-bit compiler as a walkaround does not sound like solution for me. I have 64-bit os, so I will be forced to use some kind of emulation to run 32-bit app on it just because of buttons glitch.
And I have noticed that it has been reported as CAR but could not find it on any page. And 7 months have passed since, new LV release is out but no patch or any update on this matter. If I just knew that someone is taking care of it and it will take that or that much time, or it will not be resolved at all and all LV version now will behave like that.. That would be ok, but here we are with no update at all. 
Sorry for my harsh tone, couldn't hold my tongue..

0 Kudos
Message 33 of 66
(4,279 Views)

@Zyga wrote:

Using 32-bit compiler as a walkaround does not sound like solution for me. I have 64-bit os, so I will be forced to use some kind of emulation to run 32-bit app on it just because of buttons glitch.


That's hardly a problem, as this runs "seamlessly" (1st line).

0 Kudos
Message 34 of 66
(4,274 Views)

@Zyga wrote:

 If I just knew that someone is taking care of it and it will take that or that much time, or it will not be resolved at all and all LV version now will behave like that.. That would be ok, but here we are with no update at all. 
Sorry for my harsh tone, couldn't hold my tongue..


As for now, it is recognized as a bug, that apparently the 10-20 (50?) people in this thread find annoying. It's reasonable to assume that other issues have higher stakes. And that would actually be reasonable from their PoV.

 

I agree that this is hard to sell to customers, so I'll just repeat that argument.

 

Debugging apparent randomly appearing\disappearing issues is hard.

 

What would really help, is a way to reproduce this problem. I've seen it happen, but I have no idea what causes it. I've seen it go away too.

 

If we could say: "do this then it breaks", it will definitely speed up a solution.

0 Kudos
Message 35 of 66
(4,273 Views)

@Zyga wrote:

Using 32-bit compiler as a walkaround does not sound like solution for me. I have 64-bit os, so I will be forced to use some kind of emulation to run 32-bit app on it just because of buttons glitch.
And I have noticed that it has been reported as CAR but could not find it on any page. And 7 months have passed since, new LV release is out but no patch or any update on this matter. If I just knew that someone is taking care of it and it will take that or that much time, or it will not be resolved at all and all LV version now will behave like that.. That would be ok, but here we are with no update at all. 
Sorry for my harsh tone, couldn't hold my tongue..


Unless you really can't live without the extra memory space that 64-bit applications give you, NI recommends that you use LabVIEW 32-bit, regardless of the Windows bitness.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 36 of 66
(4,259 Views)

wiebe@CARYA wrote:

Debugging apparent randomly appearing\disappearing issues is hard.

 

What would really help, is a way to reproduce this problem. I've seen it happen, but I have no idea what causes it. I've seen it go away too.

 

If we could say: "do this then it breaks", it will definitely speed up a solution.


It is random, and I do not know reason too, but it happens very often - 50/50 times I start my app. I suppose something must go wrong when IDE/RT loads because it has never happened after program/vi was running. Always from its first run and only LV/EXE restart can help. And if I remember good this happens also on linux (where btw is no 32 bit option anymore ) - but this have to be confirmed because it is was long ago when I used LV on Linux.

 

To be perfectly honest I use LV 64 bit with no particular reason. I just got used to it because of medical data projects I was working on in the past. And if I knew that this will take so long to fix it I would have surely migrated to 32-bit version before this project has started. Still to be considered but bit of compiling and testing ahead of me.

 

 

0 Kudos
Message 37 of 66
(4,249 Views)

@Zyga wrote:

wiebe@CARYA wrote:

Debugging apparent randomly appearing\disappearing issues is hard.

 

What would really help, is a way to reproduce this problem. I've seen it happen, but I have no idea what causes it. I've seen it go away too.

 

If we could say: "do this then it breaks", it will definitely speed up a solution.


It is random, and I do not know reason too, but it happens very often - 50/50 times I start my app. I suppose something must go wrong when IDE/RT loads because it has never happened after program/vi was running. Always from its first run and only LV/EXE restart can help. 

Not for me. I'm sure I see this happen during development, and I've seen it go away during development. 100% sure about this.

 

I think it's 'instance based', I have clones and sometimes one clone doesn't have it, and another does. But once the original VI has it, all clones get it. But this is not 100% sure.

 

I'd expect it has something to do with a pointer not being 64 bit in a 64 bit application. But that's also a wild guess.

 

This could even be a Windows bug? Those are system controls... It wouldn't be the first time. I'll have a look. EDIT: Not a lot to be found. Nothing conclusive...

 

 

0 Kudos
Message 38 of 66
(4,234 Views)

@Zyga wrote:

To be perfectly honest I use LV 64 bit with no particular reason. I just got used to it because of medical data projects I was working on in the past. And if I knew that this will take so long to fix it I would have surely migrated to 32-bit version before this project has started. Still to be considered but bit of compiling and testing ahead of me.


Using 32 bit LabVIEW isn't a solution. It's a workaround at best.

 

Plenty on questions are answered by "why not use 64 bit LabVIEW", so when you do use it, "use 32 bit LabVIEW instead" is just not right... Might as well recommend to use Python or Java instead, that would also solve this problem. Probably.

0 Kudos
Message 39 of 66
(4,233 Views)

wiebe@CARYA wrote:

Plenty on questions are answered by "why not use 64 bit LabVIEW", so when you do use it, "use 32 bit LabVIEW instead" is just not right... Might as well recommend to use Python or Java instead, that would also solve this problem. Probably.


The general advice still is: Unless you really need >3GB memory process space, and/or have DLL drivers that aren't available in a 32-bit version, do use 32-bit LabVIEW. 

Most Toolkits and add-ons now work in 64-bit too but if you want to do a realtime project you don't even have a choice but to use 32-bit LabVIEW.

 

Your suspicion about a pointer sized value being mistreated as 32-bit integer might be a good hunch. Those GDI handles and other GUI handles are Windows handles eventhough they don't always represent pointers. And despite Microsoft claiming at first when going to 64-bit that HWND and friends are supposed to never exceed the 32 bit range, I have seen situations where that definitely doesn't seem right anymore. Treating such a handle as 32-bit integer in a 64-bit process and then passing it to various APIs simply causes all kind of APIs to error out as the handle got invalid due to 32-bit truncation.

Rolf Kalbermatter
My Blog
0 Kudos
Message 40 of 66
(4,225 Views)