Background: I'm writing a CF 3.5 application that is to run on a WINCE 6 embedded device. I have a 2 solution setup where one solution is targeting CF3.5 and another solution targeting the full framework. I had to do this because the VS test internals require full framework. It's very nice to be able to use the full framework unit test bits. Issue: I don't have hardware as of yet, and I don't want to run a risk by assuming that because my unit tests run well on the desktop that they will run fine on the embedded device. I would like to constrain the memory use that my components are allowed to use. Is there a way, directly or indirectly, to accomplish this?

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I also recommend looking at the performance of your program too. I think you're not storing huge amounts of continuous data. I use a profiler http://www.red-gate.com/products/dotnet-development/[^] to help me spot nastiness. When collecting data from devices, it pays to make sure that your program runs smoothly and doesn't accumulate extra memory. I know it's a little off topic, but doing performance analysis has helped me quite a bit.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

1. The first 'for' loop does not use its indexer. You can easily change the 'for' loop to a 'foreach' loop and iterate through the bytes. This will simplify your code a little. 2) Do comparisons of bytes, don't convert to strings. 3) If you're working in hex numbers use hex numbers throughout your code, don't mix up number bases. This will make your code easier to understand. 4) Your logical comparisons should use the logical && operator and not the & operator. The & operator returns a bitwise operation resulting in a number, not true or false. They are VERY different. 5) You should always put magic numbers in your code as constants.

   public const Byte StartDelimiter = 0x55;

You should never sprinkle those into code manually, you run a huge risk if you are forced to refactor your work. Not to mention that you may mistype one. 6) I would avoid doing tricks with your loop variable like incrementing/decrementing it inside your loop block unless it is absolutely necessary - which should be never. 7) Match your braces. Just because you don't necessarily have to put them in after an 'if' statement doesn't mean you shouldn't. IMHO. 8) Do yourself a favor and look up the State Machine design pattern, it works very well for these kinds of problems. 9) When I ran your program (with healthy fixups) I found that you presumed that every 0xCC,0xCC was an end delimiter. This, apparently, is a false presumption. CCCC appears in your third dataset as valid information, and should not be treated as a fencepost delimiter. fix that up and I think you should get valid results, or at least get you further along. Regards,

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

Let me get this straight, because I think there are language barriers here. In reference to your example data... a 'BLOCK' is considered everything between 0x55 and 0xCC right? If this is the case, then a couple of your example data sets have multiple blocks. Luc is right in his previous post that data has to escape the fencepost identifiers if they appear inside the payload. And the issue is that your dividing into BLOCKS is not working as expected? No exceptions, just not valid results, ya?

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

What exceptions are you receiving? If you could elaborate it may help get the root of the problem.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

You're exactly right. Why UDP is insisted upon is baffling.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

You have to be aware of the sequence number. It will be up to the receiver to keep track of what it has and to identify missing frames. 1,2,3,4,5,6, 7-MISSING ,8,9,10,11, 12-MISSING... etc. A quick scan through the list and you'll find the missing frames (7 and 12). The receiver would have to request that those two be resent. If all frames were ACK'd the sender is waiting for a confirmation and is waiting to send the next one in line. I've worked with systems that function like this, and the ACK-on-every-message is woefully slow on high latency networks. You just have to send and hope it gets there, and put in provisions to resend frames later on down the road. You could also pre-parse the data that is to be sent and create a manifest of sorts that is sent first. If you know exactly what to expect in a data transfer the problem gets a little easier I think.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I've done things like this with much lower level protocols. Typically I do it with ACK messages, so you send one UDP frame, then wait for the receiver to ACK before you send the next. It works well if you don't have time sensitive stuff like sending video. If you have to optimize due to lag or timing constraints, you could frame your own message protocol inside the UDP frame that would include a sequence number. That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive. I think you'll definitely have to ACK messages in some way weather it's on every message or missed ones. Hope it helps. EDIT: After re-reading your original post, maybe your protocol includes ACK/NACK. One other thing you could do is try to optimize the size of the frame you're sending so that it fills as much of the frame as possible. Look up Minimum Transmission Units or something like that. You may also want to look at waiting for the order of arrival. Your sender just sends and sends, and the receiver can ask for specific frame numbers. You could eliminate any kind of artificial turnaround wait times. It would be up to the sender to buffer and sequence packets in some way that is saved or can be calculated for retries, and up to your receiver to be able to continue to receive in spite of out of order data.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

Try using a custom iterator. Passing back a generic list is wasteful in some cases anyway.

public IEnumerable<String> GetStrings(){
foreach(var str in stringList){
yield return str;
}
}

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I know it's possible to stick a Border inside a BlockUIContainer, but it seems like under that element you can't use the FlowDocument thingies again. I haven't tried to nest a FlowDocument under a BlockUIContainer yet... somehow seems wrong. Is there a way to put rectangles (much like a GroupBox) around FlowDocument elements? Scott

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

led mike wrote:

My first suggestion is don't presume.

100% correct. I should UNlearn what I have learned. It turned out that it WAS and WASN'T a security issue. I set the default security with the way I created the IpcChannel. I had to set it up using Hashtable props that include the security settings. If I hadn't taken the shortcut and did it the right way I would have spotted this right off. Thanks for the help, I appreciate it! Scott P.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I don't know why I didn't try this before. I had the client publishing it's IpcChannel with it's string uri only, and this won't work apparently if there's any kind of security needed. You need to specify the dictionary definitions when you create the channel as follows: public static void Publish() { var serverProvider = new BinaryServerFormatterSinkProvider(); var clientProvider = new BinaryClientFormatterSinkProvider(); IDictionary props = new Hashtable(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; props["name"] = "Client"; props["portName"] = LogOnInformation.LogOnChannel; props["typeFilterLevel"] = "Full"; props["exclusiveAddressUse"] = "false"; props["authorizedGroup"] = "Everyone"; props["rejectRemoteRequests"] = "true"; var chan = new IpcChannel(props, clientProvider, serverProvider); // this has to be unique ChannelServices.RegisterChannel(chan, false); client = new LocationViewProxy(LogOnInformation); RemotingServices.Marshal(client, LogOnInformation.LogOnHost, typeof(LocationViewProxy)); } Thanks to those of you who looked. Scott P.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I have a publish/subscribe application running on a single machine. The system uses 2 ipc remoting channels, one set up on the installed service (which has no issue) and another set up on a client. The client sends uri information to the service via the service's remoting channel so telemetry can be sent to the observing client. I can connect to the service and do everything I need to do with it's ipc channel, but when I try to connect to the client's channel I receive an Access Denied error. The service is installed as "Local System" permission. I presume that this is a security issue but I can't seem to get it right... Any suggestions? Thanks! Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I'm not so sure you can distinguish that info with the socket alone. I've always spun up a new thread or created new objects to deal with the new socket connection, so I knew that they were different. If you need some kind of identification, you'll need to transmit that information from the client to server on a connection, or request it from the server. Bottom line I think is that you'll need to program it into the client. Hope that helped... Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I think the best way to do this is with a custom formatter, that way you'll be able to reuse it. Google it. I think what you're looking for though is this:class Program { static void Main(string[] args) { Int32 number = 234; String s = number.ToString().PadLeft(9, '0'); Console.WriteLine(s); Console.ReadLine(); } }
Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

*sigh* I'll probably get downvoted for this, but here you go. The only way I know how to do this is with Visual Studio and using C# because I presume you knew that this is a C# forum, right? Don't ask me how to use this with Embedded Visual C. 1) Use Visual Studio to set up a smart device project 2) Connect PDA with tether - you may need to use ActiveSync 3) Build/Test using the emulator 4) Deploy with VS to device when you're satisfied with results Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I'm trying to use a bluetooth device as though it were a socket. I am aware that this can be done using WINSOCK and P/Invoke, but to be honest I really don't want to put myself through that just yet X|. With WMI I can get the MAC address that the BT Dongle is using, but can I use the MAC Address to create a socket with .NET? Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

No. If you chain constructors, the compiler is smart enough to put members initialized in the class body into the last chain target. I went back through and verified this. Here is some sample code for you to compile and run ILDasm on. Car has chained constructors, where Truck does not. Truck's constructors all get the initialization code for the CultureInfo member, where Car has the initialization for CultureInfo in the constructor that takes 2 args. using System; using System.Globalization; namespace ConstructorChainKata { class Program { static void Main(string[] args) { } } public enum Market { Production, Concept, Military, Custom, Armored } public class Car { private String manufacturer; private Market market; private CultureInfo targetLocale = new CultureInfo("en-US"); public Car(String manuf) :this(manuf, Market.Production) { //.. } public Car(String manuf, Market markt) { manufacturer = manuf; market = markt; } } public class Truck { private String manufacturer; private Market market; private CultureInfo targetLocale = new CultureInfo("en-US"); public Truck(String manuf) { manufacturer = manuf; market = Market.Production; } public Truck(String manuf, Market markt) { manufacturer = manuf; market = markt; } } } Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

I have a .NET service that collects data from custom hardware. I want clients to log on to the service so I can do the Publisher-Listener pattern to publish updated data to the clients. Right now I have remoting objects that both sides use that are basically event containers. Server gets new data, server gets listener objects from listener collection, server transmits new data via the event to the client. Client observes event, unpacks and updates. Is this the best way to do this? The way it's laid out now seems hackish just to have classes that are nothing more than event containers. I also need additional scaffolding on both sides to observe the events and client request calls. The system is safety critical and the prototype application leaves a bad taste in my mouth. Does anyone have a different approach other than the event container, or should I get some mouthwash (or some bourbon) for the bad taste? Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

Right. Also if initialization of any kind is put into the body of the class, it will be injected into every constructor when compiled to IL so it will tend to bloat up classes with multiple constructors. If you're a real performance nazi you'd have to take nuggets like that into consideration because the JITer will inline code under 32 bytes. See Here. Scott P.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin