|
Wrap your "payload" in your "meta-data", and add it to a System.Collections.Concurrent.ConcurrentQueue<t> hosted in a service-type application.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Hello,
by rewriting a MFC App
In .NET I want to declare huge bulk data, which should be placed in the exe.
Because I see, with the resource techniques the access to data implemented with resource-techniques are only possible with streams,
I want to prepare the data, e.g. by declaring long arrays.
Have you a tip for me?
Thank You
Erhy
|
|
|
|
|
Erhy wrote: Have you a tip for me?
Yes, do not do it that way. But without more detail of what problem you are actually trying to solve it is impossible to say more.
|
|
|
|
|
the App is a speaking keyboard
and when a key is pressed the sound should
played immediately.
So the wave data has to be available in memory.
The App should start fast.
The only reason to port from MFC to WPF is
to have more beautiful dialog.
Erhy
|
|
|
|
|
What "data types" are you working with?
The simplest array is a bit or byte array.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
the data are .wav files prepared for XAudio2.
The longest file has 163 KB
|
|
|
|
|
Erhy wrote: Because I see, with the resource techniques the access to data implemented with resource-techniques are only possible with streams,
I want to prepare the data, e.g. by declaring long arrays.
So presuming that the arrays do not exceed some limit in .Net itself, which you would need to test...
1. Create the array(s).
2. Write code that wraps the array(s) in a Stream.
You might need several classes for 2 depending on the exact stream that you need but you can start with the 'MemoryStream' class and research it from that.
I would expect that you should experiment with creating a new stream each time or attempting to keep a single instance. The former shouldn't be a problem because you are using a memory blob so the object cost is low.
If there is some reason that your data is unusual you might need to create your own stream class.
|
|
|
|
|
Thank you for thinking about.
I want to avoid streams, because with XAudio2 the usage of pointers is necessary.
XAudio2 cannot used straight with C# .NET, rather such interfaces are necessary:
[SuppressUnmanagedCodeSecurity]
[DllImport(XAudioDll, CallingConvention = CallingConvention.StdCall)]
internal static extern int XAudio2Create(IntPtr ptr, int flags, XAudio2Processor flags0);
|
|
|
|
|
Not sure what you mean.
You mentioned streams so I provided a solution that allows for a stream but a in process one (not file based.)
With speech you are going to need to pass a large amount of binary data using some api. Any implementation is either going to do that via an array or a stream even if the exact implementation is hidden.
Presumably you have an API of a library not under your control and you are using it. If it takes a stream then you pass it a stream (my in process solution.) If it takes an array then you pass an array (which you presumably already know how to create.)
|
|
|
|
|
I hoped for using pointers in unsafe mode of C#, but I failed.
Now in a test project I have 250 C# files in the form
namespace WavDatSpace
{
unsafe public static partial class WavDats
{
public static byte[] WAVEA = {
0,0,220};
}
}
and with VS the building of the project needs minutes,
also when I change only one file.
How to do it better?
Erhy
|
|
|
|
|
Move your resources to a separate project and stop building it every time.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
is it possible without DLL ?
|
|
|
|
|
If you add a Gb worth of data, and change some code so it needs be recompiled, then yes, it will take long. If you don't want that then make sure it isn't compiled each time by splitting it into its own assembly.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks,
while developing I will make an extra DLL with data
and in the final version I will include the byte array with data
in the body of the exe project.
Erhy
modified 29-Aug-17 9:52am.
|
|
|
|
|
I primarily work with WPF apps, so for now, let's limit this to that...
How would you tell other instances of your app that something has happened, or to take some action?
Example of messages might be:
- Force Logout
- Record added to table
- Record is locked/unlocked by a user
- User has logged in/out
I've been learning SignalR and this seems like the perfect tool for the job. Anyone have any other ideas?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: How would you tell other instances of your app that something has happened, or to take some action?
I usually don't, but when forced to, I'd use a queue in the database and poll that. There'd be a slight delay, just as GMail has.
Kevin Marois wrote: Record added to table
I wouldn't; I dislike the idea of lists growing while you're working with it. Or worse, data changing while you are editing 
Kevin Marois wrote: Record is locked/unlocked by a user
Again, I wouldn't; has never been a problem to let the database handle that.
Kevin Marois wrote: User has logged in/out
I wouldn't; even if both apps are on the same desktop, only the active one (the one with input-focus) would be logged out.
Kevin Marois wrote: Force Logout
I wouldn't; the server would simply return an error-condition on the next request, similar to Sql Management Studio.
To answer the question; yes, it seems like SignalR is a usefull communication-package. Now running a compiled script on a webhost may have the advantage of being very cross-platform, I would certainly not call it "realtime". Anything sent to a browser and digested by JavaScript is very noticeably "not realtime".
Kevin Marois wrote: Anyone have any other ideas?
I think that SignalR might work better in a web-environment, for those who are building web-apps. For a desktop-application I'd prefer a simple socket (and not another dependency), unless there is a very compelling argument against it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: I usually don't,
I agree with that sentiment myself. I found myself questioning even the need for some of the posted examples in the OP. Certainly when someone suggests such a need I usually question why it is needed in the first place.
|
|
|
|
|
jschell wrote: Certainly when someone suggests such a need I usually question why it is needed in the first place.
I doubt that the web has such need, but since someone built a solution, there will be specifications demanding this "realtime" logout.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I suppose such a solution could be used if you had a system where you had to roll an update out at a certain point in time. Your server could send out the notification that the update needs to happen and log the application out - and yes, I have seen systems that do this in practice.
This space for rent
|
|
|
|
|
I can see how that would be preferred to looking at an old UI with cached JS. Users all over the world would not be able to work with the product after the update, simply because they're still on an 'old page'.
Not a problem to update Sql Server and disconnect some clients if you're on a desktop
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Pete O'Hanlon wrote: Your server could send out the notification that the update needs to happen
I can see several potential problems with that solution.
1. What if the client app does not receive the notification.
2. What if the client app is in the process, right at that moment, of making a request to the server.
3. As a specific example of 2 what if the app is in the process of doing a long running process, such as uploading or downloading a large file.
4. What happens if the update is actually to the notification service itself?
|
|
|
|
|
Yup - it's not 100% safe.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: Yup - it's not 100% safe
Name something in coding that ever is.
Not doing something about a problem doesn't make it go away
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote:
Not doing something about a problem doesn't make it go away
Code, all code, can introduce problems.
If you introduce code to 'fix' a problem then the fix itself can introduce problems. So such fixes should not be introduced unless problem is something that can reasonably be expected to occur AND if it occurs it would significantly impact business functionality.
|
|
|
|
|
We could come up with "what ifs" all day long to try to discredit any proposed solution. Some of them are valid and must be considered, but you also don't want to get into "Analysis Paralysis" where you study the problem forever and never do anything about it.
Having said that, my idea was primarily aimed at the notion of preventing other users from editing data while another user currently is. In this scenario your points don't really apply.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
