I would strongly question the suitabilty of C# (or any other sort of "managed" code, e.g JVM based) for embedded code.
If your embedded code is executed on a processor with at gigabyte of RAM, you might successfully run e.g. a user interface written in a dotNET (or JVM) language. But for hardware-related functions, such as handling I/O device buffers or interrupt handlers, managed code is not your first choice.
If this is a life and death matter then cost is no object. In that case, hire a team of Software Engineers to Reverse Engineer the existing code. One tool I have used is IBM Rational Rhapsody. It's about $50000, but if it's that important, cost should not stand in the way.
You can't; well you can but the complications arising from such an activity would take years to get right. And as soon as the exe file is rebuilt all your addresses will be wrong. It seems to me you are trying to solve a problem that does not exist. You need to put all your text data in some file format that only your application can understand which is far less difficult than trying to hack the executable.
Can only conclude from your evasiveness you're trying to modify someone else's exe and you don't have the source code. Otherwise, you would make a large enough array to hold any "future" "patched" entries.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
I've got a Windows Forms (C#) project with a combobox that is populated when the form loads
The problem is that the loading of the combobox is slow, and since the loading is done when the form is trying to display the entire form isn't shown until the combobox have been populated. This can in some circumstances be 20+ seconds.
I've tried the code below, using async and await , but it not works....return error :
"This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread."
Any help will be appreciated....
privateasyncvoid Form1_Load(object sender, EventArgs e)
await Task.Run(() =>
OleDbConnection con = new OleDbConnection(conex);
string strSQL = "select * from Customers order by cust_name";
OleDbDataAdapter adapter = new OleDbDataAdapter(new OleDbCommand(strSQL, con));
DataSet ds = new DataSet();
mycombo.DataSource = ds.Tables;
mycombo.ValueMember = "code";
mycombo.DisplayMember = "cust_name";
catch (System.Exception erro)
MessageBox.Show("Error.... " + erro.Message);
Thanks for reply Holmes, but there are aprox. 34,000 records to load from the table 'Customers'.....and I can´t filter only 100 or 200 records, because the user needs to choose a customer from the list....
And there is your problem! That is sheer lunacy, think about the workflow from a users POV. He/she approaches you form, they MUST know something about the customer before they start, they are not going to pick a random customer from 34k.
You MUST allow them to enter some text (usually 3 characters) to filter the selection if the name is the criteria, THEN you populate the combo.
If the name is not known the they must have some other information to filter the list by - geographic, product, size, credit rating, there must be some knowledge about the customer they can use to filter the list.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
This isn't a limitation of C#, but of how Windows and controls work.
The combobox control you drag over from the toolbox is just a wrapper for a standard Windows control from the Common Controls Library. The way these controls works requires sending messages to the controls to get them to do things, like add an item to a collection in your combobox.
Not working... as I mention previously, the MessageQueue.GET... methods show the Public and/or Private queues but not the OutGoing Queues...
I can "create" outgoing queue by send message with exact syntax of connection but can't get the list of current outgoing queues...