Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Last week
  3. I'll be there as well. Since this will officially kick off my vacations, I will not be presenting this year 🙂. I'm eager to sit back, relax, learn and chat with all you guys & gals.
  4. I'll probably be able to attend a presentation or two each day. I'll also be there for the Tuesday night meetup at the Hideout.
  5. It is solved now. I unchecked the exclude PPLs and DLLs in the build spec of LF.lvlibp And moved the resulting LF.lvlibp to the same directory as the other PPLs.
  6. I have a legacy application I am updating to use LV2019. It has an installer for the application which installs the run-time engine and the application itself (and a bunch of other stuff). This is done using InnoSetup and not NI's installer creator. Previously, I was able to run the RTE install in totally silent mode where no popups or anything came up on the screen, I would like to do the same thing but cannot use the same parameters as 2019 uses the new NIPM format. I can get the installer to run through from start to finish with no user interaction using: install.exe --passive --accept-eulas --prevent-reboot However during install it pops up its own dialogue. Does anyone know how I can suppress this dialogue?
  7. Your right, there is a reference leak here. That Queue is a reference created in the actor's calling code, and is used to trigger the "Autoshutdown" message when the caller stops, thus invalidating the Queue. There is an async component called the "ReferenceMonitor" which watches that Queue and sends the Autoshutdown message then closes. ReferenceMonitor also polls the actor's address, so it can shut itself down if the actor dies. However, I forgot to destroy the Queue in that case. Here is an image where I have added the needed Close operation: Thank for spotting this, -- James
  8. Thanks for explanation, so I shouldn't worry about those. I am asking because I have some stability issues with code and trying to pinpoint it with DETT toolkit. What might not be normal is these startup handshake queues, they should be released after "Ack Startup" right?
  9. Indeed. In my circumstance though, I don't really care too much for the output, I have some downstream code that waits a bit and checks for correct generation of a PDF file I am creating.
  10. The only thing to add to Neil is that the Wait Until Completion should be True if you are going to read the standard output after it is complete.
  11. @Brainiac did you solve this in the end? The code below shows how I do it, this works completely fine for me on Windows 7..10. The Generation Batch File is the complete path on disk, I don't use the Working Directory input.
  12. Hi Jim, Here an exemple. I just see that this example does not allow to resize the window. I will try to find a way to be able to do so. I know that there is a way in C# explain in this video. Let me know if this helps. SizeWindowToTab.zip
  13. I'll be there, presenting a regular session and a 7x7.
  14. Thanks, Benjamin! Any chance you could post your example VI? I can't seem to place the snippet PNG.
  15. I’ll be there. I’m excited to see everyone.
  16. Negatory, I've been going every other year and NI Week every other year.
  17. Yes, these references are intended to only be closed when the actor that created them stops running. The term "reference leak" is used by the trace toolkit to indicate any reference cleaned up by LabVIEW when a vi goes idle, regardless of whether it is an actual leak.
  18. Is it normal to have reference leaks on "Parallel Process Library\Create ID notifier.vi" and "Async Execute Core.vi" when shutting down, using startup type 2? When using Startup type 1 only "Parallel Process Library\Create ID notifier.vi" has reference leak. Tested with "vi.lib\drjdpowell\Messenging\Testing\Test Queue Actor Folder\Test error on startup.vi" See picture of trace execution, I''m on LV2018 and latest messenger lib.
  19. Hi Jim, Have you try to use the Region Functions from the Windows API? You can download an LLB that call this API on here. Below an example base on the size of a Tab control. Hope this helps. Benjamin
  20. Has anyone noticed that if a window (A) has no titlebar AND (B) is resizable, then it will have a white stripe at the top of it? (see screenshot below, and note that the big titlebar is not actually a titlebar, but a styled button, and the actual titlebar is hidden) Has anyone figured out how to get rid of this white strip (perhaps with Windows API calls)? I know I can get it to go away if I make the window NOT resizable, but I don't want that -- I need to be able to resize. I've done a little googling and the only thing I can really find how to set up WPF properties for the windows, and I can't seem to find any magic user32.dll calls or anything like that. Here's an example: white strip at top of window.vi Thanks for any help or ideas.
  21. Haven't been in a few years; excited to see what's new in the community and what people are working on.
  22. Rearranging the cases in the Type Specification Structure so that the default LabVIEW function is the LAST case restores expected behavior (I think)...not sure if this is what was intended...
  23. I have been transitioning my framework's core libraries to packed project libraries. Unfortunately, the higher level PPLs depend on lower level PPLs, but i think that I've managed to sort out all of the broken connections. Now the issue that is bothering me is that whenever I open a project containing a higher level PPL, I get a bunch of "VI cannot be found on disk errors" that refer to VIs within the higher level PPL. My initial thought was that the file paths were too long, but that doesn't seem to be the case. Has anyone else come across this behavior when using PPLs?
  24. I asked this on the NI forums, but no response, so I'm hoping the expertise here might point me in the right direction. I'm trying to make an application that allows a user to modify the screen size and still be able to control everything. Most of this is done by having a main vi that has subpanels that get filled up with vi's. All of this is built upon actor framework. I don't want any elements on the front panel of the vi's to change size. The only thing I want is for the position of the vi within the subpanel to change so that it is always centered. I've achieved this by taking the size of a Pane, and setting the origin to the center based on the rectangular area of all the controls. This part works great. I programmatically turn on the scroll bars if the vi won't fit in the subpanel so the user can still get to everything. (The attached CenterControls.vi is what's going on here, with the help of FP_PaneRectangeAroundControls.vi) The problem comes when a user uses the scrollbar on a subpanel. Since the inserted vi is centered, because of the origin change, I would hope the scroll bar would take that modified origin and change it. Instead it seems like whenever I use the scrollbar it takes the previous origin, instead of the one I set. By that I mean, If I change the width of the front panel, and then scroll vertically, the vi will jump to the center before the width was changed. The same happens if I change the height, and then scroll horizontally. This causes my vi's within subpanels to be thrown to where they previously were centered. You can see that behavior in the gif I attached. Anybody ever ran into this issue and know a way around it? I would like to be able to center my vi's in the subpanels, and then for scrolling to work based on the new origin. CenterControls.vi FP_PaneRectangleAroundControls.vi
  25. Broken Class adaptation in Malleable VIs in 2019: There is a difference in the code that I missed before. See the attached file with the screen shots. In LabVIEW 2018 Example Code the top level Search Unsorted 1D Array.vim has in TSS Case 1 the normal Search 1D Array function, but the start index and element are UNWIRED - thus this case would be broken. In LabVIEW 2019 Example Code the top level Search Unsorted 1D Array.vim has in TSS case 1 the normal Search 1D Array function, but the start index and element are WIRED - thus this case is not broken. The Assert Structural Type Match function is only configured to look at the Functor input - and thus with it unwired this case is selected. Malleable Nested VIM - Lesson 2B Convert to Instances.pdf
  26. A JSONtext example, ssumming all dictonary items are the same type: Alternately, keep items in JSON format so they can be treated differently at a later step:
  27. Ah, that's a cool trick. Thanks. Food for thought. Reconsidering my position...
  1. Load more activity
×
×
  • Create New...

Important Information

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