John Lokanis

QUOTE (PaulG. @ Sep 23 2008, 07:52 AM) All politics aside, you can't judge something you have never seen. Kinda like trying to ban a book you have never read. You certainly don't have to watch a movie or read a book if you don't want to, but you don't have any standing to make comments about the contents without seeing for yourself. Many people make the mistake of letting others tell them what to think. If you expose yourself to all point of view (both those you agree with and those you don't) then you will form a much better picture of the world around you. :thumbup: Sorry for the excessive smileys..

QUOTE (JFM @ Sep 23 2008, 10:58 AM) Now your thinking! What we need is something like the 'ensure visable' method in the tree control!

QUOTE (bluesky @ Sep 23 2008, 09:19 AM) Thanks for the observations. In the case of this VI, the upper loop, or 'producer' is trying to read all the data from a TCP connection (in this case a remote serial port broadcasing at 19200bps). The lower loop (consumer) is processing the data, looking for a certain string. I want to ensure that no data is missed so the top loop has to run as fast as possible to avoid a buffer overrun. It reads data in large chucks but uses immediate mode with a timeout of 10ms. So, every 10 ms it reads all the data in the buffer and passes it to the lower loop. I have been using this code for a very long time (5+ years) without having a memory overrun issue. The problem I am having now is something is killing the queue reference outside of this VI. Since the queue is unnamed, it is supported to be technically impossible for the refernce to go invalid while the VI is running and the release queue has not been called. Also, this is not the only reference that does invalid. I have error logging throughout my code that shows multiple references going invalid at the same time in unrelated VIs (all of these use 'private' unnamed queues). What appears to be happening is when some reentrant or VIT spawned code leaves memeory, it accidentally kills other queues in other instances of the same VIs. Or, something is corrupting LabVIEW's memory. NI App support is trying to reproduce the issue. I will let you all know what they tell me in the end. -John

QUOTE (JFM @ Sep 23 2008, 09:09 AM) Good point. I will add that. As far as the multiple font issue goes, I don't use multiple fonts in my text displays, so that won't be an issue for me. But, if you come up with a solution, please post it in the CRID section where I posted the whole solution. Unfortunatly, I was not able to open the code Aristos posted because I have yet to update to 8.6. I am guessing that the issue is the wrapping changes due to the bold. If I do not copy the font over, is there another way to make an exact copy of the contents, fonts and all? What about using the clipboard and the 'copy to clipboard' method? Does this preserver fonts between string controls? As PJM pointed out, if you stick to one font, this solution does work. Hopefully we can get to a truely universal solution in the future. Perhaps Aristos can add a 'Get Number of lines' method to the string control in LV8.6.1? That would do the trick! -John

QUOTE (Yair @ Sep 23 2008, 09:49 AM) I didn't try that but I did find that it would work as required by letting it be floating but not hiding it when LabVIEW was not the active window. I didn't know you chould change a dialog from modal to floating while it was running. I will look into this as well. Thanks for the idea.

QUOTE (crelf @ Sep 19 2008, 03:32 PM) Why use third party when you can do it in .NET? Here is an example that you can modify to do what you want. -John Download File:post-2411-1222130857.vi

QUOTE (jlokanis @ Sep 21 2008, 11:32 PM) Well, I think I cracked it! Here is the key: http://lavag.org/old_files/monthly_09_2008/post-2411-1222119801.jpg' target="_blank"> With this code, I was able to change the line locator algorithm to do a binary search. So, this is font independant and very fast. Please try it out. I updated it on the code repository. *New* Search Text Control -John

QUOTE (jlokanis @ Sep 21 2008, 11:29 PM) Solved the speed issue. Check out the code to see how! Remaining issues: 2. To make sure it does not get lost, I need to make it floating. But, for some reason, you cannot bring a floating window to the front programmatically. So, when it first appears, you must click in the window before you can type anything. 3. In order to make the text in the original control appear highlighted, that window must be front most. So, after it finds something, it has to set the caller's window front most. This means each time you wish to do another search, you must select the dialog window again. Any ideas on this? 4. I am using a combo box to allow it to remember past searches. For some reason, if you type the very first entry into the combo box and then press return to toggle the find button, it will not see this entry when it reads the string from the combo box. So, instead, I had to force the user to click on the Find button. Check out the new version attached to this post. -John http://lavag.org/old_files/post-2411-1222119951.zip'>Download File:post-2411-1222119951.zip

QUOTE (Aristos Queue @ Sep 21 2008, 08:56 PM) Yes, that is how I solved this for my first attempt. I have posted the code in the Code Repository in Development section. Search Text Dialog It has several areas that could see improvement. 1. Speed (it is slow). I am not up to writting a word wrap detector right now. By using the Get Nth Line function, I can support a text control with any font. I think this could be improved by doing a binary search algorithm, but I would need to know how many lines a text control contains. As noted, this is not easy and requires counting <CR> and word wraps. 2. To make sure it does not get lost, I need to make it floating. But, for some reason, you cannot bring a floating window to the front programatically. So, when it first appears, you must click in the window before you can type anything. 3. In order to make the text in the original control appear highlighted, that window must be front most. So, after it finds something, it has to set the caller's window front most. This means each time you wish to do another search, you must select the dialog window again. Any ideas on this? 4. I am using a combo box to allow it to remember past searches. For some reason, if you type the very first entry into the combo box and then press return to toggle the find button, it will not see this entry when it reads the string from the combo box. So, instead, I had to force the user to click on the Find button. Please take a look at the code and see if you can help improve it. This could be a really useful feature to share with others if it can be made bullet proof. -John

This set of VIs implements a standard text search prompt as seen in most text editors. To use it, all you need to do is pass it a reference to the text control you wish to search. The following features are provided: 1. Search in both directions. 2. Remembers past search strings from each session. 3. Can choose to match case or not. 4. Opens centered on caller. (Can override if necessary) There are some issues with this version. I could use help in improving in these areas: 1. Speed (it is slow for large amounts of text). By using the Get Nth Line function, I can support a text control with any font. I think this could be improved by doing a binary search algorithm, but I would need to know how many lines a text control contains. This is not easy and requires counting <CR> and word wraps. 2. To make sure it does not get lost, I need to make it floating. But, for some reason, you cannot bring a floating window to the front programmatically. So, when it first appears, you must click in the window before you can type anything. 3. In order to make the text in the original control appear highlighted, that window must be front most. So, after it finds something, it has to set the caller's window front most. This means each time you wish to do another search, you must select the dialog window again. Any ideas on this? 4. I am using a combo box to allow it to remember past searches. For some reason, if you type the very first entry into the combo box and then press return to toggle the find button, it will not see this entry when it reads the string from the combo box. So, instead, I had to force the user to click on the Find button. I hope this incarnation is useful to you and with help, we can make this even better. -John Download File:post-2411-1222064807.zip

I am trying to create a feature to search a text box for a certain string. I plan to implement this like the Find function you get with most text editors when you press Ctrl-F. I can use the Search and Replace function to locate the test and I can use the Text.SelectionStart and Text.SelectionEnd properties to highlight the found text, but I cannot figure out how to scroll the text box to the proper line. There is a Text.ScrollPosition property, but how do I figure out what line the text is in? Has anyone already created this and if so, can you share your code? thanks, -John

I think this is one of the best books for LabVIEW development I have ever read. Very good reference for how to write quality G code. I have all the DEVs on my team read it. ALso, there are some nice online materials available to support the book. Worth the $ if you ask me.

QUOTE (PJM_labview @ Sep 19 2008, 09:31 AM) I took this one step further and changed all my unnamed queues (except this one) to be named using a GUID (from a .NET call). So far, this has not helped (other refnums are going 'invaild' at the same time as this one). I think there is a bug in the code that manages references where clones leaving memory can somehow kill the references in other clones of the same VI. I have NI support digging into this now. I hope they can offer me a work-around.

QUOTE (PJM_labview @ Sep 18 2008, 02:23 PM) There is only one release queue in the entire VI and that is marked with a 4 in the picture. BTW: looking at the error log, I see that many refnums were corrupted throughout my program at the exact same time. I think there is a bug in the code that manages refnums. I have contected NI for support on this so we will see what they say. Maybe it is time to move up to 8.6? Maybe I should not use shared clones?

I have narrowed this down to what I think is a nasty latent bug in LabVIEW (I am using 8.5). I have attached an image to see what is happening. What it boils down to is LabVIEW is corrupting its own memory when running large parallel apps with a lot of shared clone Vis. Here is an image of my code: Looking at the image, at step 1, an unnamed queue is created. At step 2 we wait for messages to appear. The wire I marked 3 shows that the cleanup code after the upper loop is data dependant on output from the lower loop. This means that the release queue marked 4 can never execute before the lower loop completes. I get the following errors from this VI: Error 1122 occurred at Dequeue Element in BIG-IP_TESTS_TM Get Scheduler Response.vi:21->BIG-IP_TESTS_TEST Call Scheduler.vi:9 Possible reason(s): LabVIEW: Refnum became invalid while node waited for it. And then: Error 1 occurred at Release Queue in BIG-IP_TESTS_TM Get Scheduler Response.vi:21->BIG-IP_TESTS_TEST Call Scheduler.vi:9 Possible reason(s): LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. This code is run 1000s of times per day and we only see this happening 2 or 3 times per day. Since it is impossible for these error to occur due to a coding issue, there must be a bug in LabVIEW causing it to destroy a queue reference outside this process. My guesses are: shared clones can sometime step on each other *or* memory is being corrupted. Note: This VI is set to 'Shared Clone' and there can be up to 40 instances of this running in different thread at once.

My company has an opening at our Spokane engineering site. This job requires advanced skills in LabVIEW and traditional test engineering. If you are interested, send me your resume and I will get it to the hiring manager. -John

QUOTE (Val Brown @ Sep 17 2008, 10:33 AM) Not to get off topic here, but can't you use the text search to find the property node by property? Simply enter the text of the property name in the find window.

QUOTE (JiMM @ Sep 15 2008, 06:07 PM) Check out this link: http://wiki.lavag.org/Lessons_learned_from_plugins' rel='nofollow' title='LabVIEW Wiki article on Lessons_learned_from_plugins' alt='Wiki article on Lessons_learned_from_plugins' style="border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">Lessons_learned_from_plugins -John

QUOTE (Val Brown @ Sep 12 2008, 09:19 PM) By your command.... Center Dialog Box

Here is an example of how to center your dialog boxes on the front panel of your application. This uses a set of utility VIs I created that will allow you to specify the VI to center on. If you do not specify a VI, then it will search the call chain for the nearest caller who has an open front panel. If there are no VIs in the call chain open, then it will center it on the screen. I use this a lot in my applications. I hope you find it useful as well. -John Download File:post-2411-1221526151.zip

Well, I managed to get the 3 button dialog to do most of this by modifing the source code. I ended up changing the server call to center the window to instad call a subvi that takes the call chain and searches it for the nearest parent with an open window and then centers itself inside that window. This is as close as I can get to what the system dialogs do. Looking forward to the refactoring of the 3 button dialog by the coding challenge, if anyone has time to do it. If you want to add my little trick, let me know and I will post the VI. -John

Before I totally reinvent the wheel, has anyone created replacements for the one and two button dialogs that do not block the root loop in LabVIEW? The main features I would need them to have are: Ability to resize to fit message and button texts, like the originals do. Reentrant (so one does not block another, in case many threads want to call this at the same time, and yes I know this might not always make sense.) Centers itself on the active calling window (and not the screen, like the 3 button dialog does) Does NOT block the root loop! I can almost do this with the 3 button dialog, but it centers itself on the screen and is not reentrant. thanks! -John

QUOTE (jdunham @ Sep 2 2008, 05:07 PM) Yes, there is one thing very special about VITs vs reentrant clones. A VI spawned (and detached from the caller) using a VIT can run in the background and have it's FP displayed in a sub-panel and removed while it is running. A reentrant VI must be set to hidden FP in order to get it to run detached from the caller, but then it cannot be displayed in a sub-panel because it's FP is considered 'open'. So, if you want to spawn daemons with FPs that you wish to display in a sub-panel, they must be created from a VIT and not a reentrant clone. I am using unnamed queues and passing the queue reference by value to all sub vis that need it because I have many spawned copies of the same code all using the same reentrant sub-vis and I need to make sure each spawned hiarchy uses it's own queue refs and not those from another spawned hiarchy. So each queue in the VI spawned from the VIT has only one create and one destroy.

QUOTE (jdunham @ Sep 2 2008, 02:49 PM) yes. that is the case. And I do not rely on any states of USRs. Instead, I use SEQs (single element queues) to save and recall states between parallel processes within my code. I am essentially treating these SEQs as dynamic memory pointers. In my case, I launch many copies of the same VIT that call many reentrant VIs (all set to shared clones) that in turn create their own SEQs and pass them around to communicate between my producer and multiple consumers (7, in fact). So, if I was to preallocate, my memory usage would be through the roof (as it was before the shared close feature was added).

QUOTE (ragglefrock @ Sep 2 2008, 02:29 PM) Yes, in most cases I do have initialzed SRs that contain data passed from one execution of the loop to the next (consumer structure). There are a few cases where the code in one case generates a reference that is passed to the next execution of the loop. In those cases, the SR contains meaningless data until the case that populates it executes. After that, the SR has a valid refnum. This is hte one where I did not intialize the refnum. So, I suppose I could initialize it with a void refnum (in this case a queue) but I figured that would not serve any purpose other than clarity. So, it sounds like I don't need to worry about data between loop executions even if I have 100's of instances of this reetnrat VI. They should all play nice and not step on each other's data. Back the the drawing board...