Jump to content

LogMAN

Members
  • Posts

    655
  • Joined

  • Last visited

  • Days Won

    70

Everything posted by LogMAN

  1. I haven't looked into it, but the description says I assume it is capable of renaming VIs without loosing the revision history: http://sine.ni.com/nips/cds/view/p/lang/de/nid/211524
  2. I think the most annoying issue is that you can't actually rename a folder in the files tab of the project (this could be so easy!). I generally go to the files tab, select everything in the current folder, right click -> Move on disk..., create a new folder at the desired destination and press save. As this entirely depends on LabVIEW, there is no relinking done (well there is, but no search dialog). However the old and now empty folder (including the entire filder hierarchy) remains and cannot be removed because LabVIEW keeps locking it (I think it is the search location for the next save/load dialog).
  3. Which file types did you use? PNG files do generally work for me, unless you copy them from any other program (like paint). Use the "Import picture from*" function from the right-click menu instead.
  4. Your example should create a table with 2 columns (1x Numeric & 1x Text). The table name is '123' and will have 4 rows ( 1|abcd, 12|abc, 123|ab, 1234|a ). I'm not sure what you are trying to archive with it. Anyways, here is my example (did not test, but it should work if you open the database properly): If I'm correct, the database should get a new table 'fancy_table' with three columns 'column_1', 'column_2' and 'column_3'. The table should also contain a single row with data ( 'first column' | 'second column' | 'third column' ). The maximum text length for each column is 50.
  5. So the error vanished if the string length is the same. You should know, that databases have fixed length information on text columns, therefore preventing more input data to be written to it. (there are some exceptions, but I don't know about any in Access) you should manually set the size for each column in the table, there is a function to do that: 'DB Tools Create Table.vi'. If you create a table with the expected number of rows and set the text length to 250 for example, the field should be big enough to contain any possible data the user could input. Also that way you can specify the column names and use them for the insert function. Be careful not to make the field to big, as each entry will use up the entire length (unused parts are filled up with 00 afaik)!
  6. The help says: 'creates a table if a table does not exists...' But I think the problem is based on that parameter anyways: According to the help, the size of a column is decided by the size of the input data, if the table is created by that function ('create table?' is set to TRUE). Assuming that your input data does have different string-length, the columns which are created in the first iteration could be to small for the next one. Thus the function tries an 'ALTER TABLE' which does not work for some reason. If that is true, try to pass a longer string to the first iteration. Also the method Phillip Brooks described is a good practice to prevent changes to the table after it has been created.
  7. It is hard to help you if there is little to work with. The error is unknown to me, but it says that your database is read-only. So if you look into your UDL file, you can set it to read+write access (in the 'advanced' tab? - sorry, I've got a German system). Also shared access to Microsoft Access Databases is not possible afaik, so close the database in MSAccess before using it in LabVIEW. If the error does not go away, maybe you can post some pictures of your source code, the UDL configuration and database.
  8. LabVIEW 2013 is quite new and to me it is relatively normal for a new version to present annoying problems until the first SP release and .f# bug fixes. I had to switch to LV2013 from LV2011 for a single project with about 2k VIs, since the project did crash on the old version due to some architectural issues that could not be solved in time. However on LV2013 it worked quite well and even better when it comes to classes and property nodes as well as large cluster hierarchies (still some lag, but much less than before). So far I have found only one critical bug which has been solved recently: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/ Whether or not the new version is better or worse for you depends on your project size, architecture, used addons, etc... Anyways I wish NI would spend more time on fixing bugs and increasing performance of the IDE rather than implementing more and more possibly unstable features. Whenever a new version is released, the methods we do to validate the stability and usability of that version is very time consuming and more and more often leads to the choice to not update to the newer version (used 8.6.1 till 2011, and 2011 since than - 2013 is an exception after hours and hours of discussion). The main reasons to not update are bugs which cause our VIs to stop working or systems to crash after several hours. My experience is, that in almost every case the IDE is unstable because the sources are not very well designed (see discussions regarding code complexity & dependency trees). So I think as NI should work on stability and performance, we have to work on our own sources to solve bugs and decrease code complexity. Due to new features in the IDE, the code complexity will increase, sometimes without us wanting to, because we do not always understand the behaviour and/or purpose of some components.
  9. The issue has been taken care of in the related post and a fixed version of the offending VI is provided too: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/#entry106670 A future patch (currently f2) should include the fix.
  10. JeffP I've tested your file and it works just great! I can now finally see my precious preview and build the installer! Thanks
  11. Reading someone else's memory is limited by the memory protection system. Here is a link to a MSDN site that briefly describes the topic: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366785%28v=vs.85%29.aspx Whenever you try to copy memory that hasn't been allocated, there is a chance to get an access violation exception. Whether an exception occurs or not depends on the data that is accessed. For example: Assume you've allocated an array of 512bytes and one of 256bytes within your DLL. Memory is allocated in contiguous blocks, therefore the block would have a size of 768bytes. Now you accidentally read 712 instead of 512bytes of the first array, but no error occurs, because the memory is within the same block. The result would just be an array of the 512bytes of the first and 200bytes of the second array. Next you try to read 1024bytes and get an access violation, because the number of bytes overlaps the number of allocated bytes. This is just a stupid example, since there is much more to it, but this should cover the basics ( and I can't explain it much better ). Long story short: Do never access memory, that is not allocated properly! As you're calling a DLL, the allocated memory is in the same space as the LabVIEW IDE / Runtime, therefore you are trying to access data of some LabVIEW internal memory blocks, which are most likely protected. I also assume that LabVIEW does force some memory protection over all DLLs that are called in its scope. The result is what drjdpowell just posted: Yes, Microsoft is a bitch when it comes to protecting precious data. The memory management standards are now insane compared to XP. In most cases if you set the error checking options to maximum, the LabVIEW IDE will show violation errors if memory is incorrectly accessed. That might help you to pinpoint the issue. Of course there is also always a chance to crash LabVIEW because you incorrectly accessed memory... Wow, I've just wrote an article to questions that could be answered with two 'yes'
  12. I can't give you any VI, as I have currently no system with the database connectivity toolkit installed, however I would build the query manually and supply it to the 'Execute Query' VI (I don't even know how all the other VIs work ). Your query should be: notice, that: 1) 'Prueba' is the table name 2) 'date' is the column name 3) %s should be replaced with the date you want to supply (use the 'Format Into String' VI) Your value must not contain a single quote as part of the value and ID must be set as auto-increment. I'm not sure if the value must be put into single quotes ( '%s' ) or double quotes ( "%s" ) ... Hope that helps.
  13. Great, thanks! I'll try as soon as I'm back in the office the week after next week. You'll get an update then.
  14. 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...
  15. 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.
  16. 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 )
  17. 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?
  18. 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
  19. 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.
  20. 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.
  21. *.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?
  22. 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.
  23. 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.
  24. 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...).
  25. Just out of couriousity, do you use class property nodes in your project and are the VI updates related to them?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.