Francois Normandin

Yeah, I guess I abused of my privileged position with access to JKI Package Network and uploaded it straight there. I now updated UI Tools page with version 1.4.1 to match.

OK, I found the problem. The Two Button Dialog box does not initialize the excluded references before computing the text position. To correctly compute the position, one needs to exclude the text indicator so that the rest of the components are aligned properly. A quick fix while I rebuild and publish the package is to add the string reference with "Set Exclusions.vi" in the Init case of "Dialog_TwoButtons.lvclass:Dialog Box.vi". (Edit: Actually, the Set Exclusion node needs to be the first called... as opposed to the image below.)

Thanks for the report. I'll give a try to the VI you provided on a few of my installs and let you know.

Hi Bruce, I just saw your post. As cbl mentioned, the best place for support on SMOs is the issues section on GitHub. https://github.com/JKISoftware/JKI-State-Machine-Objects/issues Are you still having issues or you've solved it? It is most likely a re-entrancy settings issue, perhaps with the Splash screen template creator method. Try setting the reentrancy of the Creator method to Shared Reentrant. Francois

Bonjour Antoine, I didn't resubmit on LVTN. The approval process was long last time. I'll release it on the JKI Package Network at the first convenience!

NI has been stabilizing LabVIEW for many releases now, and has been mainly focused on performance and reliability. Speaking for myself, the absence of cool new language features or redefinition of the IDE and work flows are the main reasons I've been mostly inactive from LAVAG over the past few years. Once I've gone around the garden and experienced most of the things I am personally atuned to, I find it harder to keep an interest in the daily chatter that happens. I hope I'd get a renewed interest if I found a new topic that piqued my interest, but it might be wishful thinking. When on LAVAG, I kind of feel like I'm sitting in my favorite café: the discussions are background noise and I can't possibly follow them all, but they contribute to me feeling that I belong. It's comfortable. It's cozy. I like to sit next to familiar faces. If the ambiant noise is lower than before, it might simply be a realization that we've grown up as a community to the point where not everything needs to be said. Hey, LAVAG might be like an old couple that just takes comfort in the presence of the other, who knows.

I've tried a quick and simple example of ooCalc yesterday and it seems that AODL 1.3 is not fully compatible, at least with the latest version of Office 2016. I was able to create the ODS document and open it with Apache OpenOffice 4.1, but it was impossible to open it with MS Excel 2016 without errors. I could create and add pages, and insert cells in a row, but not in a self-resizable table, meaning that AODL does not support correctly the automated resizing of a table when you insert a cell in a random row/column (user needs to resize the collection of rows and columns in a given table). It might simply be a mistake on my part (back of the envelope PofC): mapping 1:1 with an example I saw online from 2010 does fail. I had to create workarounds for it to partially work. Since AODL support has been dropped at about the time I started the project, it seems likely that the ooCalc implementation with AODL will be error prone and not compatible with the latest openDocument standards. ooCalc will be lots of work to avoid these pitfalls and might be quite limited. I do not think that adding graphs and images was done with SpreadsheetDocuments in AODL. My takeaway is that supporting text, numbers and formulas might be achievable with a few abstractions, but so far it would be compatible only for OpenOffice and not for MS Office. ***EDIT: Compatibility issue is from the Save method().

- Updated the repo with package build spec - Removed the dependencies on OpenG methods (package is now dependency-free) - Added an explicit constructor for ooWriter (no more pre-install/post-install to backup the NIreport factory) - New palette for ooDocuments (vi.lib/OpenOffice RGT addon) - version 0.2.0 (beta) - still no ooCalc. - released the LabVIEW library under BSD (instead of LGPL). LGPL is only the AODL libraries part of the package.

Sorry, I abandoned this project a few years ago. I've uploaded the project to Bitbucket as a Git repo, if you feel like contributing or forking it for your project. I'll see to add the VI Package files shortly for easy install. https://bitbucket.org/normandinf/openofficergt

beuh... I think I'll leave that one until the next version

Ah. I renamed a bunch of controls with duplaicated names and didn't reload my package build file after I fixed them. It must be linking to the previous name. I'll have a fix in a moment for both packages. Outlook package updated to 1.1.0.3

Manu, let me know if this solves the dependency conflict: (v1.4) https://lavag.org/files/file/120-ui-tools-addon-control-class

hmm. Looks like it was meant to remove previous releases of Control addon class but I might have forgotten to change the namespacing. This looks like a self-conflict. Can you let me know which version you are using? I don't have 2011 installed as your profile suggests, but I'll try to reproduce the issue on a newer version and come up with a new package or a solution.

lava_lib_ui_tools_outlookstyle_expansionpack-1.1.0.3.vip

Vista Style: https://lavag.org/files/file/122-ui-tools-expansion-pack-vista-style/ Outlook Style: https://lavag.org/topic/11744-discuss-ui-tools-expansion-pack-outlook-style/?p=113783 hey, what can I say... it's past midnight.

I should have done that a long time ago. Please follow this link.

Sorry, this is long overdue... - Migrated to VIP file and moved the controls to vi.lib. - Removed dependencies on base package. - The controls will now be located under "User Controls" palette. Glassweb Style: https://lavag.org/files/file/124-ui-tools-expansion-pack-glassweb-style/ System Style: https://lavag.org/files/file/121-ui-tools-expansion-pack-system-style/ Outlook and Vista style packages to be updated tomorrow...

Jimmy, that's a good find. However, it seems like it's not doing what it's supposed to...

Hi Shoneill, Indeed, there would be a lot to do would we have an API for easily manipulating the controls properties as we can do from the editor. I've briefly looked into it but gave up for lack of time (and will) to reverse-engineer it. I wasn't able to quickly whip up the positioning of a decal programmatically, so I didn't go further with scalable graphics and all. Therefore, the Controls addon package still only replaces a non-scalable graphic (PNG) by another one created on the fly, "mimicking" a static decal of your choosing, so it is definitely not good for anything that rescales or grows with a pane. One bit of information that is quite useful for designing new buttons is this LabVIEW ini key: enableSecretPopups=True which exposes plenty of new things in the editor. You are absolutely right that the Resource Manager methods are the key here. All items are stored in chunks. All image strings (decal included) are their own chunks. The "FPHb" chunk is the one that changes when you move things around. Find the prototype for this chunk and you can probably automate it. Changing a decal changes the MNGI chunk (containing the PNG string) and a buunch of other chunks (history, size and position, etc.) Hope this help a bit.