ShaunR

Ditto what Rolf said about corruption. Here's the PtrToStr VI with Rolfs suggestions. PtrToStr.vi

I think I may know what's going on here. char *s; /* If a string user is responsible for * allocating memory. */ The "v" in your cluster is actually a pointer to char so v in your cluster should be an array of bytes which *you* will initialise with n bytes. i.e. You have to create the pointer. The function obviously copies data into your string (byte array) which is why you have responsibility for allocating the memory, rather than the function allocating the memory and you copying the data into LabVIEW. So you are going to either something like this: or this What are you doing? The second one?

Yeah. Didn't think I'd get a definitive answer since size_t is only guaranteed to be greater than 15 bits. For MS it is UINT_MAX, which could be anything. The only way to know for certain is to test the compiled environment but even then it depends on things like if functions use 32 modular arithmetic. I don't think it can be resolved conclusively in LabVIEW but the choice is only unsigned pointer sized integer or a conditional case for target bitness. I guess you are alluding to the conditional for "most likely not to fall over in most circumstances" That's what they said about disk drives and look what happened

Is that regardless of Application bitness? Should this be a unsigned pointer sized integer or is a more complex solution required to ascertain the OS (target) bitness?

Are you sure you don't have a pointer to an array of strings?

If you are tryin g to dereference a string pointer then try this. PtrToStr.vi

From your project image you seem to have many conflicts. It's likely that you are picking up another version or VI's in a different location in your project. You need to resolve the conflicts before any troubleshooting can occur.

There's a UI User group over on the Dark Side. If you hunt through it there are a few UI's like Star Trek, Media Interfaces and iPhone simulations.

It seems the biggest problem you have is the axis grid colours. Try a dark grey! Splitters can't be placed on native tab controls-just one of the reasons we don't tend to use them. The other main reason is they make a mess of your main VI trying to control them. The tab xControl above uses VI panels (the tab panel is a subPanel which loads a VI when you click a tab) so you can use splitters on the pages and also means each page is self contained and doesn't pollute the main VI's event structure. It's things like you are highlighting which are the limitations of the LabVIEW UI. It's fairly easy to have nice graphics that make your Application look nice but as soon as you try to use it, the aesthetics generally falls to pieces. A lot of the time it's like in Windows 10 when you suddenly get a Windows XP dialogue when you've spent ages creating a theme... but worse. Really worry when your manager insists on all file dialogues being the same as the Windows 10 ones

Splitters are your friend. This is one app that I've had for a while. Splitters are used to segregate the different sections and most controls are just default ones. There are no issues with maximising etc. The hard part is the button bars and Tab Bar which are actually xControls. (this is the example for the buttons bars xContol) (This is the example for the tab xContol) The most annoying for me is the things you said you don't care about. lol.

"The software you are refactoring had one and it is too costly to change the training materials". How's that? It is likely that a great deal of pressure had to be applied to even allow a rewrite and the manager probably had a hard time arguing for a budget to do it. Getting hot under the collar over a button isn't a hill I would die on. I would concentrate of making my life easier supporting it going forward than what it looked like-which was decided a long time ago.

The glib answer is that LabVIEW is a tool for engineers who generally prefer function over form. The actual reason is that the LabVIEW UI is limited, difficult and clunky to modify from the defaults. Just pop up a menu for example (no icons, can't change the background etc). The ability to create our own controls is also fraught with issues and extremely time consuming. The the only real option is XControls - which are a bit hit-and-miss. Give on-the-fly theme changing a go and you will quickly run into trouble with many controls. Making a pretty UI can double or triple the project time in some cases. There is also the subjective nature of "good looking". I hate the flat, monochrome icons that are all the rage, for example. What I may think is "cool", you may think is ugly.

I vaguely remember some beautiful UI's. It might have been a coding challenge since there were quite a few - can't really remember now. I just remember thinking "wow, I'd never have the patience for that, but that is awesome". Mine tend to be very utilitarian with the occasional lip-service to aesethics.

Lots of applications have an exit button in toolbars. They tend to be older since menu's became the preferred way to exit as not all applications had menus in those days. But historically test and automation were full screen, single purpose applications - often with touch screens - and it's hard to click a window button if there is no window titlebar.

Stop isn't to close an application. It is closer to a reset. It is to stop/terminate/curtail the currently executing task and return the application to a known state. The application is still running. The application is still initialised and the application is still in contact with devices. In desktop terms; a "Stop" is to an exit/close as an exit/close is to a reboot. Not all applications need a Stop button (think of things like Notepad) but if you have a Start button you will probably need a Stop button.

. Yes. If my muscle memory hadn't kicked in it would have been paltry.

ECL 4.0.0

It's not my problem, so to speak, about how they accomplish it. Personally, I would go with an off-the-shelf HTML rendering engine for FP's - which is, in effect, what I have already done.

I think you are missing the point. We can handle *most* things in UTF8 due to the primitives we have but what we can't do is display any of them on a FP. I don't really care if that is a windows limitation or not. If NI have to write a UTF8 renderer for their controls, then so be it. While they are at it, they could make the nonsense we have to go through to colour text much easier too.

That sounds like I would be shooting all the toes off of my feet as well as the feet. We already have this for UTF8. What we can't do is display it (ignoring the file control for now). If you roll your trouser-leg up and poke your tongue out at the right angle; you might get the ini switch and the associated property to sort of work for some encodings. But I ditched that a long time ago in favour of HTML and I don't remember it working for UTF8.

We already have the UTF8 primitives that cater for 99% of cases The real problems are indicators and controls (I'm looking at you, file control). I would be happy if we could display and use UTF8 in controls and indicators. I don't really care about other encodings as I could always convert them to UTF8 for the edge cases. Also. Wouldn't need a special wire

I find it mildly amusing that a non-native English speaker knows more about my language than I do. Maybe if I had gone to Grammar School and learnt Greek and Latin, I would be more equipped to argue. However. I got an F in French so it probably wouldn't have gone well

If it's just the time you are working in LabVIEW-that is doable without writing something for windows. You could just monitor open LabvIEW windows and or projects (count them if you want). You can make it easier by namespacing VI's (e.g. myproject_someFunction) which, to be honest, I generally do as a matter of course. At a bare minimum and If you are working in projects, all you need is to monitor projects in memory and timestamp when they appear and disappear. Not folder activity-more of a project activity.

Nice. I guess there is something very LabVIEWy now!