Jump to content

John Lokanis

Members
  • Posts

    797
  • Joined

  • Last visited

  • Days Won

    14

Posts posted by John Lokanis

  1. Does anyone know if there is an ini setting somewhere that will allow me to change the recent file list in the getting started window?

    Under the 'Open' section, it lists recent projects and files. This list matches the file..recent projects/file menu. The problem is, it only lists the two most recent projects. Since the majority of my day-to-day work revolves around several projects, I would like to change this so it lists more projects and less files. Two is just not enough and I end up using the drop down menu instead most of the time.

    I know this is a minor inconvienence, but it just bugs me after awhile. There should be some why to change this...

    thanks for the help,

    -John

  2. QUOTE (jlokanis @ Sep 21 2008, 11:29 PM)

    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.

    1. Speed fixed. Uses binary search. One caveat: it will only work with single font string controls. So, no mixing fonts or adding modifiers (bold, etc). If you can find a way around this, please let me know.

    2. By setting it to float and always visable (do not hide when LV not active), I was able to make it be the top window when it is activated.

    3. Still no improvment here.

    4. Needed to set the button to both toggle and grab focus when <CR> pressed. This way, the data being entered into the combo box becomes 'active'.

    Thanks to everyone who helped improve this code. If you have any other ideas or suggestions, please post them and I will see if I can improve it more.

    -John

    http://lavag.org/old_files/post-2411-1222277716.zip'>Download File:post-2411-1222277716.zip

  3. QUOTE (Aristos Queue @ Sep 23 2008, 03:06 PM)

    You'll have to find a new champion for that. Font runs and string controls are an area of LV I don't typically work in these days. :-)

    I think this is one area of LV where it fails the 'general purpose' language test badly. We really should have text display controls that allow rich text, html rendering and support cut and paste of data that contains multiple fonts. And don't get me started on the fact that the string control scroll bar does not respond to the mouse wheel! :headbang:

    As it currently stands, I can find no way to solve this issue. You simply cannot clone a string controls data EXACTLY to another string control.

    Oh well, it works well for my use case (single font with no special formatting). I guess that is the state of the art for now...

    On to the other issues:

    1. Anyone know how to solve the highlighting issue? Can you have text highlighted in a stirng indicator when it is not in the frontmost VI?

    2. How can I have the combo box 'see' the new entry when the user presses <CR> when it is bound to the find button?

    thanks,

    -John

  4. QUOTE (PaulG. @ Sep 23 2008, 07:52 AM)

    You couldn't pay me to watch a Michael Moore film. :thumbdown:

    All politics aside, you can't judge something you have never seen. :nono: 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. :book: :thumbup:

    Sorry for the excessive smileys..

  5. QUOTE (bluesky @ Sep 23 2008, 09:19 AM)

    Your vi makes a number of assumptions. It assumes that the second while loop can process the data in the time it takes the first while loop to acquire it. If it does not the number of elements in the queue will grow very quickly. Are you sure your second while loop can process the data as fast as it is acquired? Are you sure your CPU is fast enough to acquire and process the data simultaneously. Also what thread are you running this vi in?

    Naming the queue is a good idea. Also try declaring the size of the queue and check the queue to see if it is full before you enqueue another element. My guess is that Labview is not dequeing the elements fast enough. I have had similar problems and was able to track the problem by monitoring the queue status while the vi is running. Use the get queue status vi to monitor the queue.

    If you don't declare the size of the queue Labview has to constantly allocate more memory for the newly acquired data.

    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

  6. QUOTE (JFM @ Sep 23 2008, 09:09 AM)

    ou should also consider copying the "Enable Wrapping" property

    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

  7. QUOTE (Yair @ Sep 23 2008, 09:49 AM)

    I haven't tried, but what happens if you make the window modal and then programmatically change it to be floating?

    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.

  8. 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">post-2411-1222119801.jpg?width=400

    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

  9. 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

  10. 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

  11. 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

  12. QUOTE (PJM_labview @ Sep 19 2008, 09:31 AM)

    This is a good idea; you could even use the clone instance name as the queue name since it is already unique.

    PJM

    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.

  13. QUOTE (PJM_labview @ Sep 18 2008, 02:23 PM)

    Just to make sure, you don't have a release queue in the true frame of the upper loop right?

    PJM

    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?

  14. 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:

    post-2411-1221770180.jpg?width=400

    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.

  15. 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

×
×
  • Create New...

Important Information

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