LogMAN

So I'm on the dark side now? http://lavag.org/topic/16925-controls-change-positions-on-runtime-system/?p=103828 neil, I am your father... maybe...

Thanks JeffP for the update. I've installed the patch, but unfortunately, this does not solve the issue. I still get <Error generating preview> in the installer dialog.

No, the RSS shows topics which recently received a new post with the most recent one on the top (there has been a Feed from 2011 some days ago -> 'Editing an Existing Class'). New topics fall automatically into this category though. Anyways I have the choice to follow a topic and not see all 10+ posts of one I don't really care about... Don't get me wrong, I do use the 'View New Content' Area, when I'm forced to, but I guess I'm just lazy ( and I'm frustrated when stuff does not work as intended ) ( Also, it seems I'm not too lazy to complain about it )

It seems that all the SPAM is finally breaking down the Database. Thus the RSS is now down for good: BTW, Am I the only one whose depending on this function?

To clarify something here: A 32-Bit application does never have to deal with a 64-Bit pointer! Therefore you only have to deal with different pointer sizes on 32-Bit vs. 64-Bit applications which of course depends on your LabVIEW IDE at compile time. There is also no way you could call a 64-Bit DLL from a 32-Bit application. Now to the question at hand: I think a pointer sized integer could help in many situations if you want to support both bitness types. However this is only true if you can be sure, that the same library call could in fact link to two separate libraries. For example, the kernel32.dll could be called from either a 32Bit or 64Bit application from the same location (C:WindowsSystem32kernel32.dll), but the 32Bit application is redirected to a different file at runtime. This is very well described here: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx If you want to write an application that supports both types (depending on your LabVIEW IDE), I suggest you handle all data in 64Bit integers and depending on your bitness, typecast to the lower bitness on 32Bit calls (This is what LabVIEW does with the SZ or USZ afaik). The bitness can be determained by a conditional disable structure, as described here: http://digital.ni.com/public.nsf/allkb/F9770A64A5D5EF4A862576E8005985A8 In my opinion, a pointer-sized integer would be nice to have as a choice for integer representation. However it must be made very clear, that the number of bits does change depending on the IDE bitness, as using it the wrong way could cause serious problems in some situations. Anyways I have some situations in mind where I would like to have such a type

I have no solution for you, but this is how my machine works: 1) Creating a file from LabVIEW in C: will return an error Error 8 occured at Open/Create/Replace File in Untitled 1Possible reason(s):LabVIEW: File permission error. You do not have the correct permissions for the file.C:test.config 2) Create a subfolder (e.g.: 'C:New Folder') now writing the file to this location works perfectly fine. I did not have to change any properties for the folder at all. The UAC is set to 'standard'. And in the folder permissions, authenticated user are allowed to do everything except 'full access' and 'special rights' <-- these might be spelled differently, as I translate from my German system. It dosn't seem to matter if the file is *.config or *.txt. As it is a Windows OS, there are some possibilities that could cause such issues. So here is a list of things you could try: 1) Install all the latest service-packs & updates (Win7 SP1 must be installed, since there have been many issues before) 2) Check again if your account is really of 'Administrator' type (An account with 'User' rights can read the files, but not write) 3) Try running LabVIEW 'As Administrator' explicitly. (This must work) BTW, I always assume you are running an development system. Is that right, or are we talking about a Runtime system? For a Runtime system you need to unlock the executable at least.

Well I use this function if there is a single spam around (I actually did that on the very first spam-post), but there have been 100+ posts since, which are hard to keep up to. However you should have received 8 more reports just now . I don't think it's necessary to read all posts, since the titles in the RSS are quite obvious. However if reporting is how it has to be done, you can be sure I'll send reports.

*.config files are Application Configuration Files which are treated as system files afaik. UAC will of course prevent you from editing system files, unless you have full read/write permission. It seems that the directory you use to store the files does not grant full read/write permission. Did you add your user name in the permission tab for that folder?

I think hooovahh pointed out the correct way to deal with a situation on a Runtime system (Yes, the documentation of the feature could be better & you unlock for certain directories only!). However if you don't need the UAC (like for a standalone system nobody really cares about), just disable it entirely. I figure the latter one to be more like a 'workaround' solution, but you gain access to any file location without setting up all required directories manually. If your application has no predictable default behavior, it could be a pain to setup an installer for a system with UAC enabled.

Count me in. The spam is to much to compensate in the last weeks and so many topics are lost/unseen in the process. It seems to be a single bot/person that will go on for some time. The moderators are doing their job, but that will not be enough if this goes on. I think a post limit is a good start, however it should be a limit to new members (like for the first 1-2 Weeks after creating an account?), thus limiting the amount of damage and providing the community with the ability to recover very quickly. However the spammer will eventually figgure out a way to generate new accounts automatically, which will cause a new flood of spam with or without the limit. An additional way to deal with spam is to allow regular members to mark somebody as 'spammer' in order to limit his movements or even temporarily remove the latest (like today) posts of a suspect until a LavaG Moderator looked into the matter personally. This feature should only be entrusted to members who are in club 500 or higher (and the premium members I guess). As the moderators cannot keep up with the spam (sorry, but I guess the community is much faster here), this might be a way to get rid of such situations in the future very quickly by the community itself. And the moderators still have full control over the situations and what happens to such accounts. Just an idea though and I have no clue how complicate such a function would be to implement. However the community here is great and could be entrusted with this in my opinion. A LabVIEW captcha (aka CLAD questions) is not very helpful and could easily be avoided, once all the possible solutions are known. If it has to be a captcha, use a regular captcha (picture with random numbers/characters). Anyways LavaG would loose much of its flavor this way. I like how we are trusted without such a security measure.

Thanks for the update JeffP I recently opened a new topic in the 'LabVIEW Bugs' forum to track the issue in the future (forget to post it here though ) http://lavag.org/topic/17166-error-generation-preview-in-installer-properties-caused-by-automotive-diagnostic-command-set-120/?hl=429636 The INI token is indeed very helpful, but unfortunately very difficult to discover (If it wasn't for Neil I would still be stuck...).

Just out of couriousity, do you use class property nodes in your project and are the VI updates related to them?

The Automotive Diagnostic Command Set (ADCS) in version 1.2.0 when used will prevent the installer to generate a preview, set properties of any application executable, and building the installer, due to a bad linked VI. The installer dialog will just show '<Error generating preview>' in the application details section. I got this issue on a new installation of LabVIEW 2013 and this behaviour has since been reproduced by an NI technician. A bug report has been filled in: CAR 429636 There is currently no way to build the installer including the application. It is not possible to add the offending VI to the library, as the library is locked & password protected. My solution was to build an installer for just the additional installers (runtimes, etc..) and to manually copy the application files to the target system. Here is a copy of the issue details from the initial thread that is also linked below. Please reffer to the thread to get more detailed information about the circumstances that causes the issue (and to see some actual pictures): ----- The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Here is the important line of the build log: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. ----- Notice: I was able to start the build, because the installer has already been configured in LabVIEW 2011 SP1 & ADCS 1.1.0. Here is the related topic: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

Unless you remove a VI from its library, it will stick to it, even if you try to load it without the library. However if you load a VI that is part of a library, you can disconnect it (File -> Disconnect From Library). I think there is also a possibility, to break the library, if you replace a VI of the library with one that is not linked to it (I have not tested this though). This is why I avoid to edit VIs while the library is not loaded.

I think we stick to much to the BD, where the FP also needs much more love As I checked for new ideas in the Idea Exchange, I found an interesting one: Check this link: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Match-widths-of-Label-and-Caption-input-fields/idi-p/2579739 I like this idea so much that I couln't help but giving it kudos

Hi mwebster, I've downloaded your VI and confirmed the behaviour on my Win7 system on LV2011. The stepping effect as in your diagrams however never occured to me. I think the term 'drift' is misleading you here. The 'date/time in seconds' value will always drift slightly to the 'tick count', as the tick count is less accurate (significant digits missing & tick counter is rounded!). You can see that in your graph which has a range from -0,0006ms to +0,0008ms on my attempt. Thats a range of 14µs! For example: date/time: 15,3388772010803223 tick count: 15,3390000000000004 difference: -0,0001227989196781 That's what causes the effect of 'drifting' in your graph, as the timer needs many iterations to line up again in terms of microseconds. Eventually both values will round up again and the cycle starts from the beginning. There is always a chance, that one of the two functions is executed slightly after the other one, since your system is not a real time system and the functions are of different compexity inside. Also non-realtime systems have a common habbit to suspend execution of some threads to allow execution of other ones. Maybe thats causing the stepping effect in your graph eventually. Depending on the number of CPU cores and the way Microsoft handles threads (this also changed between XP / Vista / Win7 / Win8 / ... ), your experience might change too. I'm not sure though, why your XP system had a difference of 800ms... I remember something about one of them may be handled by the bios instead of the CPU... A quick search turned this out: http://digital.ni.com/public.nsf/allkb/4E12F6841016929D86257126007A9D94 I assume that the system made an synchronization to it's time over the internet at some point over the weekend. If the computer is not connected to the internet, I've no clue. As for the differences you are asking for: The date/time is more accurate and absolute, where the tick count is less accurate and relative to the start of your system (ms since start). If you need an accurate way to display execution times or delays, the tick count is everything you need. The system can only be handled down to ms anyways. Use date/time whenever you need an exact timestamp.

Hello again! I'm back to report the problem / solution. The <Error generating preview> in the installer dialog is caused by a bad VI from one of NIs Toolkits! The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Thanks to neil who made the suggestion to add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Where the IDE dialog just showed me an error: -1! !!! error -1 !!! Here is the important line: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project ) As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP. I hope this prevents anybody else to run into the same problem. Thanks for the support and the helpfull suggestions, my project is now OCD conform

Well the project is still broken. I know the part/VI in my project that causes the issue but I'm not sure why, so I'm currently in contact with NI to find a fix. I will surely post the solution once I know what is going on...

Thanks for the advice neil! Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious) I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable I can see the preview now, if I completely remove that specific VI from the dependency! Maybe I'm halucinating here, but I'll now contact NI for further investigation and may update once I got answers. Thanks for the support!

My bad, I missed the part where you said 'project-based conversation dialog'. Let me recollect something: The dialog that appears will in fact list all the LabVIEW items in your project: The enumeration process might take a while depending on the number of files in your project but there has never been a loading screen for me. Be aware that all files within the project (VIs, libraries, llbs, auto-populated VIs/libraries/llbs, etc...) will be enumerated (except for files under 'dependencies'). Have you ever reached that dialog at all? It's not clear for me. If you never reached that dialog, it should be rather safe to kill LabVIEW (it's enumerating files) -> I assume your dialog does only say 'Loading:' and not 'Compiling:' as in your screenshot. It seems like LabVIEW is trying to load everything (the entire LabVIEW directory?) into memory (..LabVIEW 2012resourceFramework* is part of the LabVIEW core!). So you could abort that operation and try on an empty project file. If you have the same behaviour again, it would be a good time to contact NI. If you want/have to abort the process, you should check the object cache first. If the size changes, than LabVIEW does remove compiled code. Killing the process then might result in broken VIs. It is located under: C:Users<your user name>DocumentsLabVIEW DataVIObjCache<your labview version>objFileDB.vidb So for me that would be: C:UsersLogMANDocumentsLabVIEW DataVIObjCache12.0.0r4objFileDB.vidb

There are quite a few items loaded and I'm not sure how the sources will react if you kill LabVIEW (some of them might have their compiled code removed while others dont). It wouldn't be a big issue if you had your code in SVN or something where you could just revert the working copy... (I recommand to create a backup before doing such stuff anyways) However if you have a single project file and want to remove compiled code from VIs within the project you can do that from the project properties dialog (Seperate compiled code from new project items & Mark existing items) I recommand to use that function as it is shipped with LabVIEW (at least since 2011 afaik) I used it on my recent project with 1000+ VIs and it took just a couple of minutes. Just read the thread you linked: Seems that LabVIEW 2010 had some issues with the removing of compiled code. As you are using LabVIEW 2012 that should be no issue, so why using that VI instead of the build-in function anyways?

Hi hooovahh, Well I use a DLL file in my project that has been created in LabVIEW 2011. This should be no issue, but would have made my application to load both runtimes (2011 for DLL & 2013 for EXE) so I managed to recompile the DLL in 2013. This is what I mean by upgrading "it". As for the preview: If you create an installer, you want to tell it where to store the application files. For that the installer dialog will automatically generate the preview in order to provide the files list... I also want to provide a menu shortcut to the executable which I cannot create if there is no preview that includes the actual executable (it is basically as if it doesn't exist at all!). The preview generator (in the application specification) is very quick for large applications. Hi neil, It seems I'm not the only one who had problems lately. Lucky me, as I now have an experienced bug tracker I did as you suggested: I mass compiled all the project folder and cleaned up the orphan & bad VIs unless there was no error left, but still no improvement. Here is what I did: 1. Mass compile project folder (returned some warnings about Bad-VIs & Missing VIs) -> Due to orphan VIs in my folder structure (removed!) 2. Mass compile project folder (still returned a bad VI) -> Removed it from my project library 3. Mass compile project folder (no error) -> Still can't see my preview in the installer dialog 4. Mass compile shared company libraries (no error) -> Still preview error 5. Clear compiled object cache (I use SVN, FYI) 6. Mass compile project folder (no error) -> Still preview error 7. Create a new project; add all necessary files; create an application specification; create the installer specification -> Does not work (preview error) 8. Mass compile vi.lib (did only take about an hour or so & returned a bunch of errors -> masscompile.txt) I did stuff like: - Restart LabVIEW - Reload Project - Recreate Project every now and then, but in the end there was still this <Error generating preview> text. Well I'm ready for my weekend but if there are any more suggestions I would be happy to try them out! Nice weekend to everybody!

Hello everyone, I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project. However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues ) I'm still able to build the application executable with no problems too! Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an installer. The configuration dialog shows 'error generating preview' for any executable in the project: Naturally I tried to generate the preview in the executable, but there seems to be no issue: Creating new specifications did not solve the problem and even creating a whole new project file and including the startup VI to it + creating new specifications did not solve the problem... I made a new project with a single VI for testing if the application builder is not working in general, but thats not the case, as I was able to create an application + installer with no issues. So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project that are build in an older version (as one of the dll files), so I upgraded it... with no success... Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer? What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull? Any ideas are welcome

Well... Removing the topic does help... Thanks misterious someone works for me again.

As much as I don't want to bring this topic back, the feed is broken again! This time check out that post here and read the title... Since the post is quite new, the problem is currently in line 232 of the RSS. My XML check (notepad++) gives me a parsing error: Can anybody confirm this?